> ## Documentation Index
> Fetch the complete documentation index at: https://developers.respondent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo video checklist

> Step-by-step instructions for recording your staging implementation review demo

Before we issue production API credentials we ask you to record a short
screen-capture walking through your integration in our **Staging
environment**. This guide expands the [Staging Implementation Review
section of our production requirements page](/docs/Getting-started/requirements-for-production-credentials#1-staging-implementation-review)
with concrete instructions on what we want to see.

We're looking for evidence that your **product** can drive the
Respondent API end-to-end. For every required action below, we want to see it
trigger from your own product UI and then see the resulting state in
both your product UI and Respondent's UI.

***

## Before you record

* **Staging researcher login** — have your Respondent staging researcher account ready in another tab. You'll switch to it to show state changes.
* **Test participants** — seed at least a few using `POST /v1/profiles` (the same endpoint you've been using to test). See [Staging Environment](/docs/Getting-started/staging-environment) if you need a refresher. You can [sign in as those participants here](https://website.staging.respondent.io/next/participants/login) to apply to your own project and to reply to messages.
* **Recording tool** — any screen recorder is fine (Loom, QuickTime, OBS, Drive upload, etc.). We just need to be able to play it and reference timestamps. Narration is encouraged but not required — if you record silently, please use on-screen labels.
* **One or two videos?** — your call. If you support both human-moderated and unmoderated studies, you can put both in one video with chapters, or send two shorter videos. Whichever is easier.
* **Token hygiene** — keep API tokens, secrets, and any real user PII off-screen. Staging tokens are still credentials.

***

## Recommended structure

This is a suggested order — feel free to deviate if your integration's natural flow is different. What matters is that every checklist item below is covered somewhere in the recording or written notes.

1. Intro (\~30–60s)
2. Project setup (per study type you support)
3. Happy-path lifecycle — Invite → Mark as attended
4. Disqualification, quality rejection, and reporting
5. Human-moderated flows (if applicable): scheduling + messaging

***

## Checklist

> If a checklist item doesn't apply to your integration (e.g. you don't support unmoderated studies, or your flow skips a particular action), include a brief written note explaining why. This helps us review faster without coming back with clarifying questions.

### Written items

> Include these in the message when you send the video.

* [ ] Confirm **auto-pay is enabled** on the projects your integration creates.
* [ ] List which **study types** your integration supports (human-moderated, unmoderated, or both).
* [ ] List which **screener question types** your integration supports (e.g. multi-choice, free-text, number range, etc).

### 1. Intro — orient us

* [ ] State who you are and what your product does in 1–2 sentences.
* [ ] Tell us which study types your integration supports — **human-moderated**, **unmoderated**, or **both**.
* [ ] Briefly outline what we're about to see (which flows, which study type first, etc).

### 2. Project setup

> Demonstrate once per study type you support.

* [ ] From your product UI, create and publish a Respondent project that includes **at least one screener question**.
* [ ] Show the published project in your product UI.
* [ ] Switch to [Respondent's UI](https://website.staging.respondent.io/) and show the same project, published.

### 3. Happy-path lifecycle

> Demonstrate once per study type you support.
>
> Take **one** screener response — one that arrived qualified from screening — all the way through. You can use a test participant you've seeded via `POST /v1/profiles` and applied to your project.

* [ ] Show the qualified screener response appearing in your product UI (the list/inbox/whatever your users see).
* [ ] **Invitation** — two paths depending on your integration:
  * If your integration uses **auto-invite**, just show the response landing at `Invited` status in your product UI and in Respondent's UI.
  * Otherwise, trigger [**Invite participant**](/screener-responses/invite-participant) from your product UI and show your UI and Respondent's UI reflecting the invite.
* [ ] **For unmoderated studies only** — demonstrate the participant going to the task (e.g. sign in as the test participant and follow the task link from their dashboard).
* [ ] Trigger [**Mark as attended**](/screener-responses/mark-as-attended) — this can be manual or automated. For unmoderated studies, "attended" represents task completion. For moderated studies, it's typically triggered after the session ends (calendar callback, researcher action, etc.). Show your UI and Respondent's UI reflecting it.

### 4. Disqualification, quality rejection, and reporting

> Doesn't need to be the same participant — pick any screener response(s).
>
> For each item, explain or demonstrate when this is triggered in your flow (manually or automated).

* [ ] Trigger [**Disqualify**](/screener-responses/qualify-participant) from your product UI — a Qualify call with `qualifyStatus: false`. Show your UI and Respondent's UI reflecting it.
* [ ] Trigger [**Mark as rejected**](/screener-responses/mark-as-rejected) on a response (this is the post-invitation "quality didn't meet expectations" action, distinct from disqualifying at entry). Show your UI and Respondent's UI reflecting it.
* [ ] Trigger [**Report participant**](/screener-responses/report-participant) on a response. Show your UI and Respondent's UI reflecting it.

### 5. Human-moderated studies — scheduling and messaging

> Only required if you support human-moderated studies.

* [ ] **Scheduling** — handle scheduling on your side. After a participant books a time, call [**Schedule participant**](/screener-responses/schedule-participant) to write the booking back to Respondent. Demonstrate by signing in as the test participant and showing the booked time on their Respondent dashboard.
* [ ] Show a **two-way** message exchange using the [Messaging API](/messaging/create-a-conversation):
  * Send a message to a participant from your product UI.
  * Sign in as that test participant and send a reply.
  * Show the reply appearing in your product UI.

***

## When you're ready

Send the recording (or a shareable link) plus the written items above to **[partnersupport@respondent.io](mailto:partnersupport@respondent.io)**. We'll get back to you with either approval to proceed to production credentials or any follow-up questions.

If anything in this checklist is ambiguous for your integration's shape, just ask — it's much faster than re-recording.