Research API integration is the work of wiring a customer research platform — recruitment, AI-moderated interviews, and analysis — into your own product, so your users launch studies and receive structured findings without leaving your app. This checklist takes a product and engineering team from a first API key to a production integration, grouped into six phases you can work through in order.
It is the builder’s companion to the research infrastructure platform, which explains the underlying stack, and to the pillar on building customer research into your product, which explains the strategy. This page is the operational punch list: what to check off in each phase, in what order, and where the specifics live in the API documentation.
Why build research into your product instead of bolting on a tool?
Because a panel, a moderation engine, and an analysis pipeline are each a multi-year build, and your users do not want to leave your product to run a study. When research is a separate tool, the research question that arises mid-workflow — a new feature ships, a metric drops, a customer objects — usually goes unanswered because switching tools is friction. When research is an API call your product already makes, the question gets answered in the flow.
The integration also compounds. Every study your product runs adds to a searchable knowledge layer your customers can query later, so the tenth study is worth more than the first. That compounding is why the isolation and export decisions below matter more than they look: they determine whether each customer’s intelligence stays theirs and stays useful.
Here is the whole path at a glance.
| Phase | What you do | What it unblocks |
|---|---|---|
| 1. Access | Sign up, generate an API key, read the docs | Authenticated calls |
| 2. Connect | Choose REST or MCP, wire auth, make a first test call | A working round-trip |
| 3. Multi-tenant | Map each customer to an isolated workspace | Safe production data separation |
| 4. First study | Create a study, choose panel or your customer’s list | Real interviews in the field |
| 5. Results | Retrieve structured JSON, surface it, handle the async wait | Findings in your UI |
| 6. Go live | Reliability, quality-only billing, monitoring, export | Production readiness |
Phase 1 — Access: sign up, generate a key, read the docs
The goal of Phase 1 is a valid API key in your environment and enough of a mental model to know which calls you will make. Nothing here touches production, so move fast.
- Sign up at app.userintuition.ai/sign-up — the Starter plan is free, includes three interviews, and needs no credit card
- Generate an API key from Settings — a single key of the form
ui_sk_authenticates every call, with no separate scope configuration to manage - Store the key in your secrets manager, never in source control or client-side code
- Skim the MCP server overview to see the full surface — study creation, recruitment, interview execution, transcript analysis, and knowledge retrieval
- Decide, roughly, which capabilities your product needs first: fast panel polls, full moderated studies, or queries over accumulated findings
The three free interviews are enough to build and validate the entire integration before you spend anything. Treat them as your integration budget, not a demo — running a real study through your own code in Phase 4 is the fastest way to surface the questions the docs do not answer.
One decision to make early rather than late: whether an AI agent will drive research in your product, or whether conventional application code will. That choice shapes Phase 2, and it is the fork between the REST API and the MCP server.
Start free, integrate before you spend. Three interviews, no card, the full API surface. Get an API key →
Phase 2 — Connect: REST or MCP, wire auth, first test call
The goal of Phase 2 is one successful round-trip: an authenticated call that returns real data. Pick your integration surface first.
| Dimension | REST API | MCP server |
|---|---|---|
| Best for | Conventional backend services, server-to-server calls | AI agents and LLM-driven workflows |
| Integration style | HTTP requests you build and version yourself | Dynamic tool discovery with typed schemas |
| Who calls it | Your application code | Claude, ChatGPT, Cursor, or any MCP-compatible framework |
| Authentication | Single ui_sk_ key | The same single ui_sk_ key |
| Choose it when | You want explicit control over each request | You want research invoked in natural language |
Both surfaces expose the same platform, so the choice is about how your product calls it, not what it can do. Many teams run both — REST for scheduled backend jobs, MCP for an in-product agent.
- Choose REST or MCP based on the table above (you can add the second surface later)
- Wire authentication: pass the
ui_sk_key as your service’s credential; for MCP, connect over stdio for local development or Streamable HTTP for production, per the docs - Make a first test call that only reads — list studies, list available languages, or list interview modes — so you confirm auth without creating anything
- Confirm the response parses and your error handling catches a deliberately bad key
- Log the request and response shapes you will depend on, so schema changes are easy to spot later
For agent-driven products, the customer interview API for AI agents walks through the tool groups an agent uses end to end, and agentic research covers what becomes possible once an agent can recruit and interview real people. The MCP consumer research integration guide is the deeper walkthrough of connecting an MCP client. Keep exact tool names, arguments, and endpoint paths sourced from the documentation rather than hard-coding them from memory.
Phase 3 — Multi-tenant: map your customers to isolated workspaces
The goal of Phase 3 is that no customer of yours can ever see another customer’s research. This is the phase builders most often defer and most often regret deferring, because isolation is far cheaper to design in than to retrofit once studies are live.
The model is straightforward: each customer in your product maps to a separate workspace in the platform, and every API call is scoped to the right workspace. Studies, participants, transcripts, and the accumulated knowledge layer all live inside a workspace, so isolation at the workspace boundary isolates everything downstream.
- Decide your tenancy mapping: one workspace per customer is the safe default; a shared workspace with project tags only works if customers never need data separation
- Store the mapping between your internal customer ID and the platform workspace ID in your own database
- Scope every call to the correct workspace, and add a guard in your code that refuses a call if the workspace ID is missing or mismatched
- Decide what read-back access, if any, each customer gets to their own results, and never expose cross-customer aggregates unless a customer has explicitly opted in
- Test isolation deliberately: create two test workspaces, run a study in each, and confirm neither can retrieve the other’s data
- Document who on your team can administer workspaces versus who can only launch studies
The compounding knowledge layer makes isolation doubly important. Because each workspace accumulates queryable findings across every study it runs, a leak is not just one exposed transcript — it is one customer’s entire research history visible to another. Get the boundary right here and the rest of the integration inherits it.
Isolation is a Phase 3 decision, not a Phase 6 patch. Map customers to workspaces before your first production study. See the infrastructure model →
Phase 4 — First study: panel or your customer’s list?
The goal of Phase 4 is a real study in the field, launched by your code. The first decision inside it is where participants come from.
| Dimension | Managed panel | Your customer’s own list |
|---|---|---|
| Who supplies participants | User Intuition’s 4M+ vetted panel across 50+ languages | Your customer’s contacts, uploaded or synced |
| Best for | Reaching an audience your customer cannot recruit | Talking to people your customer already knows |
| Targeting | Role, seniority, company size, industry, geography, behavior | Whatever segmentation your customer already holds |
| Incentives | Handled and distributed automatically on completion | Usually none — these are existing relationships |
| Speed to field | Minutes to invite, results in about 24 hours | Depends on your customer’s response rates |
| Billing | Per quality interview; only quality interviews billed | Per quality interview; only quality interviews billed |
Most products end up offering both paths and letting the customer choose per study. Panel recruitment reaches strangers who match a profile; a bring-your-own list reaches known users.
- Create a study: configure the AI moderator, the study type, the discussion guide, and the language
- Choose recruitment: recruit from the panel by segment, or invite your customer’s own contacts individually
- For panel studies, set targeting parameters — role, company size, industry, geography, and any custom screening
- For bring-your-own studies, sync or upload the contact list and confirm consent to contact is already handled on your side
- Preview the cost and timeline before launch: studies start at about $150, quality interviews are $25 each on the Pro plan, and only quality interviews are billed
- Launch against a small sample first — 10 to 15 interviews — to validate the guide and the flow before scaling up
Do not add a consent screener or a “willing to participate?” question to your guide; consent is handled outside the study configuration, and duplicating it is a UX bug. Keep your discussion guide focused on the research question. Field a small first study, read the transcripts, and adjust the guide before you commit to a larger run.
Phase 5 — Results: retrieve structured JSON and handle the 24-hour wait
The goal of Phase 5 is findings inside your own interface. Two things define this phase: the results are structured, and they arrive asynchronously.
Structured means you do not parse raw transcripts to get value. Analysis returns preference splits, ranked themes, minority objections, segment breakdowns, and verbatim quotes as JSON your UI can render directly. Asynchronous means interviews take time to field, so your integration launches a study and then waits — it does not block a request while people are being interviewed.
- After launch, poll for study status on an interval, or register a callback if your integration supports one, rather than holding a request open
- Retrieve structured results once fielding completes: theme summaries, verbatims, and segment findings, all as JSON
- Design your UI states for the wait: “study fielding,” “partial results in,” and “complete,” so your users see progress instead of a spinner
- Surface findings natively — render themes, quotes, and splits in your product’s own components rather than linking out
- For products with prior studies, add a query over the accumulated knowledge layer so a customer can ask a question and get an answer from past research in seconds, with no new study
- Handle the empty and low-signal cases: a study that returns thin results should degrade gracefully in your UI
Plan around the timing rather than against it. Standard studies return in about 24 hours, smaller moderated runs in a few hours, and rapid panel polls faster still. The knowledge-layer query is the fast path once a workspace has history, and it is what turns a series of one-off studies into an asset your customers keep returning to. The research infrastructure overview covers how the analysis and knowledge layers fit together.
Phase 6 — Go live: reliability, quality-only billing, monitoring, export
The goal of Phase 6 is a production integration you can leave running. The build is done; this phase is about the properties that keep it healthy under real traffic.
- Reliability: make study-creation calls idempotent so a retry never fields a duplicate study, and add retries with backoff on transient failures
- Quality-only billing: reconcile that only quality interviews were billed against each study, and expose that to your customers so the billing model is visible, not opaque
- Monitoring: track study status, completion rates, and API error rates, and alert on studies that stall or on a spike in failed calls
- Support paths: wire in a way for your customers to reach help, and know how to escalate a platform-side issue through the documented support channel
- Data ownership and export: confirm your export path for transcripts and structured JSON, and settle retention handling before production traffic — the data belongs to you and your customers
- Rate and load: understand the platform’s limits for your plan and shape your job scheduling around them
- Rollout: ship the integration to a subset of customers first, watch the monitoring, then widen
Quality-only billing deserves a line in your own product. Because interviews that fail the quality bar are not charged, your customers pay for signal, not attempts — and making that visible in your billing UI turns a platform property into a trust feature you own. The 98% participant satisfaction and 5/5 G2 and Capterra ratings behind the platform are worth surfacing to your customers for the same reason.
Ship it to a few customers first, then widen. Reliability, billing reconciliation, and export settled before full rollout. Read the API docs →
How does User Intuition handle the research API integration?
User Intuition exposes the full qualitative research stack — recruitment from a 4M+ vetted panel across 50+ languages, AI-moderated voice, chat, and video interviews that ladder 5 to 7 layers deep, and automated analysis — as one API and one MCP server. Your product builds on it and owns the customer relationship; the platform returns the real human signal as structured JSON. The research infrastructure platform is the front door for the stack, and agentic research is the front door for agent-driven use.
Pricing is built for embedding, not for one-off buying: $25 per quality interview on the Pro plan, studies from about $150, only quality interviews billed, and a free Starter plan with three interviews so you can integrate before you spend. If you are embedding research to resell it to your own customers, the reseller economics are worked out case by case — talk to us and we will size it to your model rather than force a standard rate card.
Work the six phases in order, keep exact tool names and payloads sourced from the documentation, and you move from a first API key to a production integration in days. That is the difference between building research infrastructure and integrating it: the panel, the moderation engine, and the analysis pipeline already exist, so your team spends its time on the part that is yours — the product your customers rely on.