---
name: sales-participant-kit
description: "Participant Kit (participantkit.com, formerly Consent Kit) platform help — an ethics-first participant & consent management / ReOps tool for UX research teams: a participant CRM and opt-in panels, informed consent forms and NDAs with e-signatures and full audit trails, screeners, scheduling, incentives, and GDPR/UK-EU data governance. REST API (Enterprise + request-only, OAuth2) over projects, studies, participants, consents, panels, and data links; no webhooks, no MCP. Use when setting up Participant Kit consent forms or panels, managing informed consent and retention for research, migrating participant management off spreadsheets, exporting panellists or consent records via the API, hitting the Enterprise-only API gate, or choosing Participant Kit vs Great Question / User Interviews / Respondent / Ethnio. Do NOT use for recruiting-and-running full studies end-to-end or a webhook/MCP research pipeline (use /sales-great-question), or the validate-before-building method (use /sales-idea-validation)."
argument-hint: "[describe what you need help with in Participant Kit]"
license: MIT
version: 1.0.0
github: "https://github.com/consentkit"
tags: [sales, pre-launch, platform]
---

# Participant Kit Platform Help

Participant Kit (**participantkit.com**, formerly **Consent Kit** — rebranded 2025-11-09, old domain
301s over) is an **ethics-first participant & consent management platform (ReOps)** for UX / user
research teams — "manage user research efficiently, cost-effectively and ethically." It owns the
operational layer *around* studies: **recruit** (opt-in panels + screeners), **prepare** (a participant
CRM, **informed consent forms / NDAs** with e-signatures and full audit trails, bulk email, scheduling,
incentives), and **respect** (accessibility/WCAG 2.2 AA, GDPR **data governance**, retention + deletion
reminders, subject-access requests). Differentiators: **UK/EU data residency**, accessibility-first,
researcher-founded, not VC-backed. Customers: BBC, Nielsen Norman Group, Co-op, TPXimpact.

Its place in the landscape is the **research-ops / participant-management** class — the compliance +
participant-relationship *ops layer*, closest to **User Interviews / Respondent** on recruiting and to
**Ethnio** on the participant-CRM side. It is **not** an all-in-one recruit+run+repository suite
(`/sales-great-question`), **not** a testing/survey tool, and **not** a synthesis/repository
(`/sales-notably`, `/sales-trill`). It does one thing well: managing participants and their consent.

**Two things to say almost every time:**
- **The API is a hard gate.** A well-documented REST API exists, but access is **Enterprise-plan only
  AND "request only"** (OAuth2 Bearer; API keys "coming soon"), with **no webhooks and no MCP**. On
  Team / Team Plus / Organisation there is **no API at all** — data-out is UI export. Say this before
  designing any integration.
- **Participant Kit manages participants, it doesn't run the study.** Consent, panels, scheduling,
  retention — yes. Usability tests, surveys, interviews, synthesis — no. If the user wants to *run* or
  *analyze* research, route it out.

## Step 1 — Gather context

If `references/learnings.md` exists, read it first for accumulated platform knowledge.

Ask only what you can't infer:

1. **What do you want from Participant Kit?**
   - A) **Consent / compliance** — consent forms, NDAs, e-signatures, audit trail, retention/deletion, SARs
   - B) **Panels / participant CRM** — build an opt-in panel, screeners, re-contact rules, move off spreadsheets
   - C) **Run a study's ops** — create a study, add participants, send remote consent, schedule, incentives
   - D) **Automate / export** — the REST API (projects/studies/participants/consents/panels/data links)
   - E) **Choose / price** — Team vs Team Plus vs Organisation vs Enterprise, or Participant Kit vs a peer
2. **Which plan are you on?** This decides everything about automation — the **API is Enterprise-only**.

Skip-ahead: if the user wants to **compare** research tools across the market, or the
validate-before-building *method*, that's a `/sales-idea-validation` question — route in Step 2.

## Step 2 — Route or answer directly

| If the user's question is about… | Route to |
|---|---|
| Recruiting **and running** studies end-to-end (interviews, tests, surveys) + a repository, or a webhook/MCP pipeline | `/sales-great-question {question}` |
| Recruiting real participants from a large managed panel (recruit-only marketplace) | `/sales-respondent` or `/sales-great-question` `{question}` |
| Comparing research/recruit/idea tools across the market, or the validate-before-building **method** | `/sales-idea-validation {question}` |
| Analyzing **existing** interview/NPS/CSAT/VoC data into themes | `/sales-customer-feedback` or `/sales-notably` `{question}` |
| Running a **real behavior** demand test (smoke-test page, waitlist, pre-sale) | `/sales-idea-validation` or `/sales-funnel` `{question}` |

When routing, give the exact command: "This is a {domain} question — run: `/sales-great-question {original question}`"

Otherwise, answer Participant Kit-specific questions using Step 3.

## Step 3 — Participant Kit reference

**Read `references/platform-guide.md`** for the full reference — the capability/automation-surface table
(API vs UI-only), best-effort pricing/plan gates, the Project → Study → Participant → Consent data model
(with JSON shapes) plus panels/fields/data-links, and quick-start recipes (consent-safe panel export,
create-study-and-participants, consent audit pull, data-link with retention reminder). **Read
`references/participant-kit-api-reference.md`** for the verbatim API surface (OAuth2 Bearer, endpoints,
JSON models, `include=pii`/`properties`, pagination, error shapes). Answer using only the relevant
section — don't dump the full reference.

## Step 4 — Actionable guidance

- **State the API gate first, every time automation comes up.** The REST API is **Enterprise-plan only
  AND "request only"** — there is **no self-serve API key** on Team / Team Plus / Organisation, auth is
  **OAuth2 Bearer** (API keys "coming soon"), and there are **no webhooks and no MCP server**. If the
  user isn't on Enterprise, tell them the only data-out is **UI export** and route a real pipeline job
  to `/sales-great-question` (which has API + webhooks + MCP). Don't design an integration without
  confirming the plan.
- **Warn about the `event_id` legacy trap.** A "study" is created/queried with **`event_id`, not
  `study_id`** (on `POST /v1/participants`), and every `app_url` contains `/events/` — the resource was
  renamed Event→Study but the wire format kept "event." Flag this whenever you show create code.
- **Treat PII as opt-in.** Read endpoints omit `email`/`name` unless you pass **`?include=pii`**;
  panellist custom fields need **`?include=properties`**, whose `field_id`s you resolve against
  **`GET /v1/fields`** (fetch once, cache). Recommend syncing the non-PII shape by default and only
  requesting PII on the narrow path that needs it.
- **Lean on consent-safe defaults.** `GET /v1/panels/:id/panellists` returns **only opted-in,
  not-opted-out** panellists, so a straight pull is consent-safe; consent records (`GET /v1/consents`,
  filter `status=agreed`/`refused`) carry `consented_at` + `permissions[]` for an immutable audit
  export. There are no webhooks — **poll** and diff on timestamps for near-real-time sync.
- **Name the plan walls before setup.** **API + SSO + custom contracts are Enterprise/Organisation-gated**;
  participant caps are **500 / 2,000 / 5,000** (Team / Team Plus / Organisation) and seats **3 / 10 / 20**;
  Team has **no add-ons**. Present all pricing as best-effort and point to participantkit.com/pricing.
- **Pick it for the right reason, and describe the actual deliverables.** When the problem is
  consent/compliance, spell out what it gives — **informed consent forms / NDAs with e-signatures, an
  immutable audit trail, and a participant CRM that replaces the spreadsheet** (plus retention/deletion
  reminders). It wins on **consent/compliance + UK-EU data residency + accessibility**, not on running
  or analyzing studies. If the user needs to **recruit-and-run** a study, route to
  `/sales-great-question`; if they need to **synthesize existing** interview data into themes, route to
  `/sales-customer-feedback` or `/sales-notably` — say so plainly.

If you discover a gotcha or tip not in `references/learnings.md`, append it there with today's date.

## Gotchas

*Best-effort from research (2026-07) — pricing (Team £60/$79 → Enterprise custom), plan gates, participant
caps, and the beta API surface all move; verify at participantkit.com/pricing and participantkit.com/docs/api.*

- **The API is Enterprise-only + request-only.** No self-serve key on Team/Team Plus/Organisation; OAuth2
  Bearer today (API keys "coming soon"). If someone expects an instant key on a paid plan, correct it.
- **No webhooks, no MCP, no documented Zapier/Make.** REST is the *only* programmatic surface — you poll,
  you don't get pushed events. For an event-driven pipeline use `/sales-great-question` instead.
- **`event_id`, not `study_id`.** Creating a participant uses `event_id`; `app_url`s contain `/events/`.
  Legacy naming from before the Event→Study rename.
- **PII is opt-in.** Default responses omit email/name — pass `?include=pii`; custom fields need
  `?include=properties` + a join to `GET /v1/fields`. `multiple_options` values come back as arrays.
- **Rebrand + old bookmarks.** consentkit.com now 301s to participantkit.com; the GitHub org is still
  `github.com/consentkit`. Same account/data — no migration.
- **Participant/seat caps are hard.** 500/2,000/5,000 participants and 3/10/20 seats by plan; Team has no
  overage add-ons, so a growing panel forces an upgrade.
- **It's not a testing/analysis tool.** No usability tests, surveys, or synthesis — don't recommend it for
  running or analyzing research.

## Related skills

- `/sales-great-question` — The all-in-one UX research platform (recruit **and run** studies + a repository), with a full automation surface (**REST API + HMAC webhooks + native MCP**). The pick when you need to *run and analyze* research end-to-end or build an event-driven pipeline — where Participant Kit only manages participants + consent. Install: `npx skills add sales-skills/sales --skill sales-great-question -a claude-code`
- `/sales-respondent` — Respondent (respondent.io) — the **recruit-only** peer: recruit + screen + schedule + pay real participants from a large B2B/professional panel via a Partner REST API, then run the study in your own tool. The pick when you need a *managed recruiting panel*, not a consent/participant-ops layer. Install: `npx skills add sales-skills/sales --skill sales-respondent -a claude-code`
- `/sales-idea-validation` — The tool-agnostic validate-before-building method + the full research/persona/validator landscape (use this to decide build-or-not; managing participants is not the same as validating demand). Install: `npx skills add sales-skills/sales --skill sales-idea-validation -a claude-code`
- `/sales-customer-feedback` — Analyze *existing* NPS/CSAT/VoC/interview data across tools into themes (the post-collection analysis peer; Participant Kit collects consent + participants, it doesn't synthesize findings). Install: `npx skills add sales-skills/sales --skill sales-customer-feedback -a claude-code`
- `/sales-do` — Not sure which skill to use? The router matches any sales objective to the right skill. Install: `npx skills add sales-skills/sales --skill sales-do -a claude-code`

## Examples

### Example 1: "How do I export our Participant Kit panel and consent records into our warehouse?" (developer/automation)
**User says**: "I want panellists and their consent status flowing into BigQuery automatically."
**Skill does**: Leads with the gate — the **REST API is Enterprise-plan + request-only** (OAuth2 Bearer,
no webhooks/MCP), so if they're not on Enterprise the only data-out is UI export and a real pipeline
belongs on `/sales-great-question`. If they are: a **polling pipeline** —
`GET /v1/panels/:id/panellists?include=pii,properties` (page 100/loop, only opted-in members returned),
join `field_id`s against `GET /v1/fields`, and `GET /v1/consents?status=agreed` for the audit trail —
diffed on timestamps. Flags syncing the **non-PII** shape by default.
**Result**: The user knows the plan gate up front and builds a consent-safe polling export.

### Example 2: "We're drowning in consent spreadsheets — is Participant Kit the fix?"
**User says**: "Different consent forms per project, no audit trail, GDPR is a mess."
**Skill does**: Confirms this is Participant Kit's core job — **informed consent forms/NDAs with
e-signatures + full audit trail**, a **participant CRM** to replace the spreadsheet, retention/deletion
reminders, and **UK/EU data residency** for GDPR. Notes it manages consent but doesn't *run* the study,
and prices it (Team £60/$79 up to 3 seats/500 participants → Enterprise) as best-effort, pointing to
participantkit.com/pricing.
**Result**: The team adopts it for consent/participant ops and knows the participant/seat caps.

### Example 3: "The interviews went great — should I build the product?"
**User says**: "We ran consented interviews in Participant Kit and people loved it."
**Skill does**: Explains Participant Kit handled the *consent + participant ops*, not the demand
question — a positive interview is not observed demand. Routes the build-or-not decision to
`/sales-idea-validation` (take the go/no-go to a real behavior test) and the *synthesis* of the
interview data to `/sales-customer-feedback` or `/sales-notably`.
**Result**: The founder validates demand with a real behavior test instead of over-reading the interviews.

## Troubleshooting

### "Where's my Participant Kit API key? I'm on a paid plan and getting 401s"
**Symptom**: You can't find an API key screen, or calls return `{"error": {"type": "invalid_request_error"}}`.
**Cause**: API access is **Enterprise-plan only AND "request only"** — Team / Team Plus / Organisation
have **no API**, and even Enterprise access must be enabled by Participant Kit. Auth is **OAuth2 Bearer**
(API keys are "coming soon," not live).
**Solution**: Confirm you're on Enterprise, contact Participant Kit to enable API access and issue an
OAuth2 token, then send `Authorization: Bearer TOKEN`. On lower plans, use **UI export** or move the
pipeline to `/sales-great-question`.

### "My create-participant call keeps failing with a validation error"
**Symptom**: `POST /v1/participants` returns `{"errors": {...}, "type": "validation_error"}`.
**Cause**: The study identifier field is **`event_id`, not `study_id`** (legacy Event→Study naming), and
`name` + `email` are both required.
**Solution**: Send `{"name": ..., "email": ..., "event_id": "sdy_..."}`. The `email` is used to send the
consent form remotely, so it must be a real address. Pass `?include=pii` to get email/first_name back in
the response.

### "My panellist export is missing everyone's email and custom fields"
**Symptom**: `GET /v1/panels/:id/panellists` returns ids + opt-in timestamps but no contact details.
**Cause**: **PII is opt-in.** Read endpoints omit `email`/`name` unless you request them, and custom
field values aren't included by default.
**Solution**: Add `?include=pii,properties`. Resolve each property's `field_id` against `GET /v1/fields`
(fetch once, cache); `multiple_options` values return as arrays, everything else as strings. Note the
endpoint only returns **opted-in, not-opted-out** panellists by design.