Key Integrations Required in a Market Research Platform: API Guide

A market research platform usually needs five integration layers to run a project from start to finish. These Key Integrations Required in a Market Research Platform include sample and panel supply APIs, survey engine APIs, fraud and data-quality services, reward and incentive APIs, and business systems.

There is also a sixth concern that affects every layer: how respondent identity and outcome data are protected while moving between systems. This part is still less standardized than most teams expect.

For a broader explanation of what these integrations do, start with OnGraph’s guide to market research software integrations. This article focuses on the technical requirements behind those connections, based on primary developer documentation.

These integrations matter more than they did a few years ago. ESOMAR’s Global Market Research 2025 report values the insights industry at $153 billion in 2024. Research software accounts for $62 billion, or 41% of the total, which is larger than the $56 billion traditional market research services segment.

Layer 1: Sample and Panel Supply APIs

This is one of the most important and technically detailed integration layers in a research platform.

Major marketplaces such as Cint, PureSpectrum, Dynata, and Kantar’s Profiles Partner Gateway follow a similar workflow. The platform requests feasibility and indicative pricing, creates the project, defines target groups and quotas, receives respondents through an entry link containing a supplier-issued respondent ID, and then returns a final outcome for each respondent.

The basic outcomes are similar across providers. A respondent may complete the survey, screen out, hit a full quota, or be rejected for quality or security reasons.

The problem is that each supplier represents those outcomes differently.

S2S codes are based on each vendor’s current developer documentation as of August 2026. Cint detects duplicates with dedicated codes in its pre-screener and client redirects, but these ultimately resolve to a quality termination on the S2S layer. Cint also uses a separate set of client-redirect codes. Kantar’s Profiles Partner Gateway is not included in the table because outcomes are routed through its Session Router instead of a public numeric mapping table.

 

Terminology also differs.

Some suppliers use one final code for the respondent outcome. Dynata REX uses a disposition to show what happened and a status to explain why. In this guide, disposition refers to the final outcome unless a supplier specifically uses the word status.

The practical result is simple: supplier integrations are not interchangeable.

Each connection requires its own outcome mapping, authentication method, configuration, and testing. Integration service providers commonly publish timelines of 2–4 weeks for simpler connections and 6–18 weeks for more complex enterprise integrations. These should be treated as vendor estimates rather than fixed implementation times.

Platforms that connect with many suppliers normally translate every provider’s codes into one internal disposition model.

That internal model is important because it stays consistent even if a supplier is replaced. The individual connectors may change, but the platform can continue working with the same internal status structure.

Authentication also varies between suppliers.

Cint’s Exchange Demand API uses JWT bearer tokens and requires a dated version header:

Cint-API-Version: YYYY-MM-DD

It also supports ETag/If-Match optimistic concurrency and idempotency keys on POST requests. Idempotency prevents a retried project-creation request from accidentally creating the same project twice.

Kantar’s gateway uses an x-api-key header across its Demand API, Supply API, and Session Router.

The legacy Lucid stack, which Cint’s Q3 2025 report scheduled for final customer migration in Q1 2026, signs webhook callbacks using ECDSA_SHA_256. Before estimating development work, confirm which API stack the supplier account actually uses.

Both Cint and PureSpectrum also provide feasibility endpoints that can return estimates without creating a project.

This is what makes programmatic bidding possible.

However, feasibility remains an estimate. It is not a reservation of respondents, and it does not lock the final price. Supply can change between quotation and project launch, so bidding systems should recheck feasibility before committing to a client.

Layer 2: Survey Engine APIs

Survey API integration connects the research platform with the system where the questionnaire actually runs.

Most major survey platforms provide HTTP APIs and use REST/JSON. This includes Qualtrics, SurveyMonkey, Alchemer, QuestionPro, and Forsta’s Decipher.

LimeSurvey works differently. Its RemoteControl 2 interface uses JSON-RPC and requires an explicit session-key handshake. The payload is still JSON, but the integration pattern is different.

Figures are based on published vendor documentation available in August 2026. Forsta publishes concurrency limits rather than request-rate limits. Limits can also vary by account or plan.

These numbers should not be compared as if they measure the same thing.

SurveyMonkey’s 500-request daily limit, for example, applies to private apps. Publishing through its App Directory can change that limit. This means API capacity can affect architecture and deployment decisions, not just configuration.

Webhooks are another important part of survey integration, but they should not completely replace polling.

SurveyMonkey publishes twelve webhook event types, including response_completed, response_disqualified, and response_overquota.

However, webhook delivery is at-least-once and events may arrive out of order. Handlers should therefore be idempotent using the response ID. A scheduled reconciliation pull is also useful for finding events that were delayed, missed, or received in the wrong order.

If a platform treats webhook delivery as the only source of truth, discrepancies may appear later during reconciliation.

Layer 3: Fraud and Data-Quality Services

Sample suppliers already run their own fraud and quality checks. The quality termination codes shown earlier are part of that process.

A research platform may still need its own supplier-independent checks.

The reason is that different suppliers use different fraud systems and thresholds. If the buyer depends only on supplier screening, it has limited independent evidence when a quality dispute occurs.

GRIT’s 2026 Insights Practice Report found that fraud-detection tools are now used regularly by 70–88% of users across the segments it tracks.

There are two common integration models.

Redirect gateways sit before the survey. CloudResearch states that Sentry can work through a survey redirect and screen participants in around 30 seconds. This approach is relatively simple to integrate because the fraud check happens at one point in the respondent journey.

Inline APIs give the platform fraud signals that it can use in its own decision rules.

Research Defender, now a Rep Data solution, exposes a v3 API that returns duplicate_score and threat_potential_score using a published 130+ signal fingerprint.

Verisoul returns normalized probabilities between 0 and 1 for areas such as account score, bot risk, and multiple-account activity. It separates a temporary session_id from a persistent account_id.

IPQualityScore returns more than 25 signals from a single GET request, including proxy, VPN, Tor, bot status, and abuse velocity.

There is one important architectural point with all these systems.

A fraud check at the survey redirect can only evaluate respondents who pass through that redirect. If panelists can also register directly through your platform API, screening should happen during registration as well.

Layer 4: Reward and Incentive APIs

Reward APIs are generally more standardized than the sample-supply layer.

Tremendous, Tango Card’s RaaS v2, and Giftbit all provide sandbox environments for testing.

Tremendous and Giftbit also document idempotent order creation.

With Tremendous, a repeated external ID returns a 201. Giftbit treats the supplied gift ID as idempotent.

This matters because reward requests often involve real money. If a network retry creates a second $25 reward instead of returning the first result, the platform has created a financial loss. Once some reward codes are delivered, reversing them may not be possible.

Delivery options also vary by provider.

Tremendous supports email, link, and SMS. Giftbit adds shortlink, direct-link, and embedded in-app delivery. Tango offers Reward Link, Promo Link, and Disbursement Link.

Fees should also be checked during vendor evaluation.

Tremendous publishes no platform or subscription fee and earns revenue through partnerships with the reward brands recipients select. Its published pricing includes 4–6% fees on cash-equivalent payouts such as PayPal, Venmo, and bank transfers. Gift cards and charity donations do not carry those same fees, while credit-card funding adds 3%.

Country and currency coverage should still be checked for every provider rather than assuming all vendors support the same markets.

OnGraph reports six reward API integrations in its panel management software for handling payouts after survey completion. This is the type of specific integration count worth asking any platform vendor to provide.

Layer 5: Business Systems

Business-system integrations are less specific to market research, but they still play an important role in completing the workflow.

Common integrations include:

• CRM systems for clients and projects
• BI and data warehouses
• Accounting software for supplier reconciliation and client invoices
• Communication APIs for fieldwork messages

Communication costs can become significant at scale.

Twilio’s US list price starts at $0.0083 for each outbound SMS segment before carrier pass-through charges of roughly 0.0035–0.005. That puts the effective cost around 0.0118–0.0133 per segment, or approximately $1,230 for 100,000 single-segment invitations.

Longer messages can cost more because they may be split into multiple SMS segments.

In the US, A2P 10DLC also requires brand and campaign registration before sending. Throughput is assigned at campaign level, so registration time should be included in the launch plan.

This is often where market research automation remains incomplete.

A platform may connect sample and survey systems but still leave supplier reconciliation and invoicing outside the workflow.

That matters because reconciliation directly affects project margin. This is why market research project management software that continues through invoicing can be more useful than a platform that stops once fieldwork ends.

The Cross-Cutting Concern: Securing the Exchange

Security requirements are not documented equally across the integration chain.

Sample suppliers often provide detailed security requirements because they carry much of the fraud and respondent-quality risk.

Survey platforms receiving those respondents may provide less guidance on how identifiers and outcome parameters should be protected between systems.

Qualtrics’ panel-company integration guide shows this clearly.

It defines identifier parameters such as id, pid, uid, and ticket, along with four redirect outcomes. However, the signing and validation of those parameters fall outside the guide.

This means the implementation team still needs to decide how to protect the exchange.

Cint documents two ways to return outcomes: an HMAC-signed redirect or a server-to-server API.

Cint recommends S2S because it can reduce problems such as ghost completes and data loss.

When signed redirects are used, the signature needs to cover both the respondent identifier and the outcome value.

If the outcome is not included in the signature, someone could potentially change a termination outcome into a completion while keeping the original identifier.

Dynata requires respondent URLs to include an access key, an RFC3339 expiration value, and a signature that the partner reconstructs and compares.

PureSpectrum uses code 31 when a respondent has altered the buyer URL. Cint uses code 134 when someone enters without the expected encryption variable.

There is still no single standard that solves all sample-exchange requirements.

TSAPI is openly licensed and supported by organizations including MRS and the Insights Association, but it focuses on survey data transfer rather than sample exchange.

The ESOMAR/GRBN Guideline for Online Sample Quality remains an important reference for sample practices, although it dates to 2015 and was published before many of today’s fraud tools existed.

As a result, the exact technical contract still depends heavily on the platforms being connected.

Where OnGraph Fits

OnGraph builds research platforms where integrations are treated as part of the core product rather than added later.

The company reports more than 65 global panel integrations and 40+ API integrations across its survey panel integration technology.

Its integration layer includes supplier and buyer APIs, reward payment systems, and fraud-detection tools.

The market research project management tool also supports S2S callbacks, hashing, and fraud-detection integrations as part of fieldwork.

The same integration approach is used in white-label survey platform projects for agencies that want to offer research technology under their own brand.

Market Research Platform Integration Evaluation Checklist

These ten questions can help determine how complete an integration really is.

1. Which suppliers are connected, and which API stack does each connection use?
Cint Exchange and the legacy Lucid marketplace, for example, are different integrations.

2. Are supplier dispositions normalized internally?
Ask to see the platform’s internal outcome model and how each supplier maps into it.

3. Can the platform request feasibility without creating a project?
This confirms whether the system can support bidding as well as fieldwork. Also ask how long feasibility results are considered valid before being refreshed.

4. Which respondent return method is used, and how is it secured?
Ask whether the platform supports signed redirects, S2S callbacks, or both, and what happens if a callback fails.

5. What are the survey-engine limits at your expected volume?
Also ask whether the system uses polling, webhooks, or both.

6. Where does fraud screening happen?
Check whether it runs at the redirect, through inline APIs, or both. Also confirm whether API-registered panelists are screened.

7. What reward options and fees apply in each market?
Country and payout coverage can vary even when two providers offer similar products.

8. Who maintains connectors when APIs change?
Cint, for example, maintains multiple dated API versions.

9. What respondent data moves between countries and systems?
Respondent identifiers are personal data. Reward systems may also receive contact and payment details. Ask for the data-flow map and retention period for each layer.

10. Can you test the integration in a sandbox before signing the contract?
Serious API providers normally offer test environments or test respondent IDs.

A product demo may not show the answers to these questions.

Ask for the supplier status-mapping table, the callback-failure process, and details of how API version changes are monitored. These are practical signs that the integrations are being actively maintained rather than simply listed as supported.