sales-skills/sales-participant-kit

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_ids 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_urls 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_ids 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.