The destination has no connector
A data warehouse, a product database, an ERP or a partner portal is not in the App Directory. Exports and spreadsheets fill the gap, and every copy is a little out of date.
SurveyMonkey · API & Custom Integration
SurveyMonkey API integration, engineered to run unattended
When the SurveyMonkey for Salesforce app, a Connect quick action or a Zapier flow cannot do what you need, the SurveyMonkey API v3 and its webhooks can. Twopir Consulting designs and builds custom SurveyMonkey integrations: the app registration and scopes, the data flows in both directions, the middleware they run on, and the retries, idempotency and monitoring that keep them correct when nobody is watching. Custom where it earns its keep, and nowhere else.
12+
500+
250+
15+
Trusted by 500+ organizations — including software, services and operations teams whose Salesforce and business systems Twopir Consulting has integrated.
What We Build With
- Salesforce Partner
- SurveyMonkey API v3
- OAuth 2.0
- Webhooks
- MuleSoft Anypoint
- Apex & Named Credentials
- Node.js & Serverless
Where packaged connectors stop short
Most SurveyMonkey integrations start with a connector and work. The calls we get come later, when survey data has to reach a system no connector covers, or when a first script written against the API starts failing in ways nobody planned for. These six are the usual reasons.
Polling eats the daily quota
Draft and Private apps start at 500 requests a day. A script that asks "anything new?" every few minutes spends that before lunch, and the limit is enforced in full after three overages in 30 days.
The app was never deployed
A registered app stays a draft for 90 days and is disabled if nobody deploys it as Private or Public. Integrations built on a developer's draft app and personal token stop on a date nobody wrote down.
The wrong data-center host
SurveyMonkey serves the US, EU and Canada from separate API hosts and returns the right one as access_url at token exchange. Code that hard-codes the US host fails for an EU or Canadian account.
Duplicates from replays and backfills
A response arrives by webhook, again from a nightly catch-up job, and again after a retry. Without a key to upsert on, each pass creates another record and reports start double-counting.
It fails silently
A revoked token, a renamed question or an expired file-upload link (they last about 12 hours) breaks the flow, and nobody finds out until a report looks wrong weeks later.
Definition
SurveyMonkey API integration, defined
A custom SurveyMonkey integration is software that uses the SurveyMonkey API v3, a REST API secured with OAuth 2.0 that returns JSON, together with SurveyMonkey webhooks, to move surveys, contacts, collectors and responses between SurveyMonkey and other systems in ways the packaged integrations do not support. It has three parts: an app registered with SurveyMonkey that holds the permissions, the data flows that call the API or receive its events, and the middleware where that code runs and is monitored.
Three parties are involved. SurveyMonkey owns the API, the app review for public apps, the scopes and the request limits, all documented in the SurveyMonkey API v3 documentation. Your systems are the other end: Salesforce, a warehouse, an internal application. Twopir Consulting designs, builds and supports the integration in between. We are not SurveyMonkey and do not resell it.
This page is about building on the API. If you are still deciding which systems your survey data should reach at all, start with our SurveyMonkey integration services. If the goal is responses on Salesforce records through SurveyMonkey's own app, see SurveyMonkey Salesforce integration. Both are part of our wider SurveyMonkey consulting and implementation practice.
Build custom only when the connectors stop
Custom code is the most expensive way to connect SurveyMonkey, and it is yours to maintain. We start every engagement by checking whether something cheaper already does the job. Often it does, and we say so.
| What you need | Usually enough | When custom becomes the right call |
|---|---|---|
| Responses on Salesforce records | SurveyMonkey for Salesforce (an Enterprise add-on): its managed package or custom object mapping, matched on a record ID carried in a custom variable. | Logic the mapping cannot express, such as conditional writes across several objects, transformation before the write, or a destination outside Salesforce as well. |
| Responses posted to Slack or Teams, or exported to a sheet | Connect quick actions, which run on every response or only on responses with a chosen answer. | The message needs data from another system, or the export has to be a governed, queryable table rather than a sheet. |
| Light glue to another SaaS tool | Zapier or Power Automate, which SurveyMonkey names for custom workflows on survey feedback. See our Zapier integration services. | Volume, history backfills, error handling or audit needs the flow tool cannot meet, or running costs that grow with every response. |
| Response data in Power BI or Tableau | SurveyMonkey's Power BI and Tableau integrations on Enterprise plans. Our SurveyMonkey data and analytics services cover the reporting design. | Survey data has to be joined with CRM, product or finance data in a warehouse before anyone reports on it. |
| Surveys sent when something happens | Flow-triggered sends from the Salesforce app, or scheduled email invitations and reminders. Designed on our SurveyMonkey automation services page. | The trigger lives in your own product or a system without a connector, so your code has to create the recipients and send the invitation through the API. |
| A SurveyMonkey integration in your own product | Nothing packaged. This is API work from the start. | Always: a Public app, OAuth for each customer account, and SurveyMonkey's review before listing in the App Directory. |
What SurveyMonkey API v3 gives you to build on
The API is broad: users and teams, surveys and questions, contacts, collectors, responses, rollups, webhooks and organization settings. These are the six parts a production integration depends on, and the details that shape the design.
Apps, OAuth & Access
Every integration is an app registered to a SurveyMonkey account. The app type decides who can connect and how many calls it can make.
- Draft apps run against your own account for 90 days
- Private apps: one SurveyMonkey team, paid plan with API access, no review
- Public apps: reviewed by SurveyMonkey, listed in the App Directory
- OAuth code flow; the code expires in 5 minutes
- Bearer tokens that do not currently expire but can be revoked
Scopes & Plan Gating
Scopes are granted per app and some need a paid plan, so the scope list is a design decision, not a default.
- Read and write scopes for surveys, collectors, contacts and webhooks
- responses_read_detail for full answers (Basic is capped at 25 per survey)
- responses_write and most collectors_write need a paid plan
- Public apps need approval to create or modify surveys and responses
- Granted scopes returned in a response header to check at runtime
Responses, in Bulk
The bulk endpoints return fully expanded responses for a survey or a single collector, which is what an extraction or sync is built on.
- Up to 100 responses per page on the bulk endpoints
- Filters by date created or modified, and by status
- Filters by custom variable, recipient, page or question
- File-upload answers as links that expire after about 12 hours
- Rollups and trends for per-question counts over time
Collectors & Invitations
Distribution is scriptable: create the collector, write the message, load the recipients, send. Your system decides who and when.
- Weblink, email, SMS and popup collectors
- Email and SMS invitations through the messages endpoints
- Recipients uploaded in bulk to a message
- Sending and contact limits apply on top of request limits
- Custom variables to carry your record IDs into the survey
Contacts & Lists
Contact lists can be kept in step with the system that owns the people, rather than re-imported from a CSV before every send.
- Bulk create and read for contacts
- Bulk add to a specific contact list
- Custom data fields on each contact for personalisation
- Lists sourced from your CRM, HRIS or product database
- Contact limits respected in the sync design
Webhooks
SurveyMonkey calls you when something changes, so the integration reacts to events instead of polling for them.
- Response completed, updated, created, disqualified, deleted, over quota
- Survey, collector and app install events
- Filtered to specific surveys or collectors
- Unique subscription URL that must answer a HEAD request with 200
- Sm-Apikey and Sm-Signature (HMAC-SHA1) headers to verify each call
Limits that shape every design: Draft and Private apps start at 120 requests a minute and 500 a day, reset at midnight GMT, with higher limits available from SurveyMonkey for a fee. Published Public apps can make up to 500,000 requests a day. The current limit, the requests remaining and the seconds to reset come back in the response headers, and a breach returns error 1040 as HTTP 429.
How the data moves, stage by stage
Most custom builds have two paths. Responses flow in, from SurveyMonkey to your systems, driven by webhooks. Invitations flow out, from the system that knows the customer to SurveyMonkey. This is the reference design we start from, and adapt.
| Stage | What happens |
|---|---|
| 1 · Event | SurveyMonkey POSTs a response_completed callback to your subscription URL. It names the event, the response ID and the survey and collector it belongs to, not the answers. |
| 2 · Verify and acknowledge | The receiver checks the Sm-Signature digest, rejects anything that fails, writes the event to a queue and answers at once. Heavy work never happens inside the callback. |
| 3 · Fetch | A worker reads the full response from the account's own regional host, using the access_url captured at token exchange and only the scopes the app holds. |
| 4 · Map and transform | Answers are mapped by question ID, not question text. Custom variables supply the record IDs that tie the response to a customer, case or order; file uploads are copied before their links expire. |
| 5 · Upsert | The write uses the SurveyMonkey response ID as an external key, so a replayed event updates the same record instead of creating a second one. |
| 6 · Reconcile | A scheduled job reads the bulk endpoint filtered by date modified and fills any gap the webhooks left, inside the daily request budget. |
Reliability, designed on our side
SurveyMonkey documents its limits and error codes. It does not document webhook retries, delivery guarantees or ordering, so a production integration cannot assume them. Everything in the right-hand column is built into the integration, not inherited from the platform.
| Concern | What SurveyMonkey documents | What we build |
|---|---|---|
| Request quotas | Per-minute and per-day limits by app type, with remaining calls and reset time in the response headers. | A shared request budget that reads those headers, slows down before the limit, and keeps a reserve for reconciliation. |
| Transient failures | Error 1040 (HTTP 429) for rate limits, and 1050 and 1051 (HTTP 500 and 503) for server-side problems. | Retries with exponential backoff and jitter for those codes only. Validation and permission errors go straight to a dead-letter queue for a person to read. |
| Missed or repeated events | Webhook callbacks carry an event ID and the response ID. No retry or delivery guarantee is documented. | Idempotent upserts keyed on the response ID, event IDs recorded to drop duplicates, and the scheduled reconciliation pass that catches what never arrived. |
| Authentication and region | Tokens can be revoked by the user (errors 1011 to 1013). Error 1018 means the request went to the wrong regional host. | Tokens held in Named Credentials or a secrets vault, never in code, the access_url stored per connection, and an alert the moment authentication fails. |
| Survey changes | survey_updated events, and answers identified by question ID rather than by wording. | Mappings on question IDs, a schema check on survey_updated, and a failed mapping that stops loudly instead of writing blanks. |
| Large reads | Paginated list resources with next-page links, at most 100 per page on bulk response endpoints. | Cursor-style paging with a saved high-water mark, so an interrupted backfill resumes where it stopped. |
| Security | HMAC-SHA1 Sm-Signature on callbacks; a HEAD check on the subscription URL; AES-256 at rest and TLS 1.2+ in transit on SurveyMonkey's side. | Signature verification on every call, least-privilege scopes, no response payloads in logs, and personal data kept only where a system needs it. |
| Monitoring | Nothing on your side of the integration. | Metrics for events received, processed, retried and dead-lettered, a daily reconciliation report, and alerts routed to an owner, with a runbook for each. |
Where the integration should run
The same design can run in three places. The right one is usually the platform your team already operates, because an integration nobody can monitor is the one that fails quietly.
MuleSoft Anypoint
For organizations that already run MuleSoft, or that need SurveyMonkey data in several systems at once through reusable APIs.
- Best when
- Several consumers need the same response data, and an integration team already monitors MuleSoft
- Shape
- A system API for SurveyMonkey, a process API for mapping, experience APIs per destination
- Watch for
- Licence cost against a single, simple flow
Salesforce Apex
For flows that start or end in Salesforce, kept on the platform your admins and developers already manage.
- Best when
- Salesforce is the main source or destination and the volume fits governor limits
- Shape
- Apex callouts through a Named Credential, Queueable or Batch Apex for volume, an Apex REST endpoint on a Salesforce Site for webhooks
- Watch for
- Callout limits per transaction, and a public endpoint that must verify every signature
Serverless or Node.js
For warehouses, product databases and anything outside Salesforce, at low running cost.
- Best when
- The destination is not Salesforce, or event volume is spiky
- Shape
- A small receiver function, a managed queue, worker functions and a secrets manager on your cloud
- Watch for
- Code your team must own: we hand it over documented, or support it
Custom builds teams ask us for
Each of these is a pattern we design for, with the API surface it uses. None of them is possible with a packaged connector alone.
Responses into a data warehouse
Webhooks for new responses, bulk reads for history, loaded as tables keyed on response and question IDs and joined with CRM data.
Surveys triggered by your product
An event in your application adds the user to a collector message and sends the invitation, with their account ID as a custom variable.
Salesforce logic beyond the mapping
Apex reads the response and writes across several objects with rules the app's mapping cannot express, then hands off to Flow.
Accounts in several regions
Separate connections for US, EU and Canadian accounts, each on its own host, with data kept in-region where your policy requires it.
Contact lists kept current
Customers, members or employees synced in bulk from the system that owns them, so every send goes to today's list.
Surveys provisioned at scale
One survey or collector per event, site or programme, created from a template by the API instead of copied by hand.
Events into systems without a connector
A completed or disqualified response opens a ticket or updates an order in a tool the App Directory does not cover.
A Public app for your customers
Software vendors connect each customer's SurveyMonkey account by OAuth, then go through SurveyMonkey's review to list in the App Directory.
Once responses arrive, what happens next is often a workflow question rather than an API one. Routing, alerts and follow-up cadences are designed on our SurveyMonkey automation page; metric definitions and dashboards on our SurveyMonkey data and analytics page.
Six stages from fit check to a monitored integration
The timeline depends on how many flows, systems and regions are involved, so we scope it in discovery and put the number in writing before you commit. The order does not change.
Fit Check & Discovery
We list each flow, its source and destination, its volume and who owns it, and test it against the connectors first. Anything a connector can do comes off the custom list.
DeliverableFlow inventory and build-or-buy decision
Architecture
App type, scopes, data-center hosts, webhook subscriptions, middleware, the request budget, the data mapping and where personal data may live.
DeliverableSigned-off integration design
App Registration
The app is registered on an account your organization owns, not a developer's, with a plan for deploying it as Private or Public well inside the 90-day draft window.
DeliverableRegistered app, credentials in a vault
Build
Receiver, queue, workers, mappings, reconciliation job and monitoring, built against test surveys and a sandbox or staging copy of each destination.
DeliverableWorking integration in a test environment
Test the Failures
Forged signatures, replayed events, a revoked token, a changed survey, a 429 at peak and a destination outage. The happy path is the least interesting test.
DeliverablePassed failure-mode test plan
Launch, Backfill & Operate
Production deployment, a controlled backfill of historical responses inside the daily quota, alerting switched on, and a runbook your team or ours works from.
DeliverableLive integration, runbook and support plan
An integration, not a dependency
An app registered to your organization's SurveyMonkey account, credentials in your vault, the code or MuleSoft project in your repository, and a design document that explains every flow, mapping and limit.
Any competent team, yours or ours, can run it from the runbook.
Feedback arrives where the work happens
Responses reach the records, tables and tools people already use, without exports or re-keying. Duplicates stop, gaps are caught by reconciliation, and a failure raises an alert with an owner instead of surfacing in next quarter's report.
Survey data becomes something teams can act on and report from with confidence.
API engineering we have already shipped
Neither project below involves SurveyMonkey. Both are Twopir API builds around Salesforce, and they are here because the engineering is the same: OAuth-secured access, filtered data, rate limits respected, events in place of polling. Each figure is scoped to the engagement that produced it.
Sotheby's International Realty (UAE)
An Apex REST service, secured by a Connected App with OAuth 2.0, that gives outside platforms filtered, project-specific listing data in real time, with audit logging and API rate limiting.
<5s Response time for filtered listings
0 Manual exports needed
24/7 Secure, audited access
Live Performance Dashboard
For a video-platform audience-growth company, Salesforce Streaming API PushTopics replaced constant polling, so a live team dashboard updates on each change without spending API calls or governor limits on queries that find nothing new, and with each partner's data kept separate.
Read the Streaming API StudyIntegration engineers who know both ends
A custom integration fails at its edges: the API on one side, the data model on the other. We work on both, and we stay accountable for what happens between them.
We will tell you when not to build
If the SurveyMonkey for Salesforce app, a quick action or a Zapier flow does the job, that is our recommendation, even though it is a smaller engagement for us.
We are Salesforce architects first
Most survey data ends up next to a customer record. We design the write so it fits your objects, automation and sharing model, not just the API response.
We design for failure first
Quotas, revoked tokens, replayed events and changed surveys are designed and tested before launch. They are what decides whether an integration survives its first year.
We build on the platform you already run
MuleSoft, Apex or a serverless service: we choose the runtime your team can monitor and maintain, not the one we happen to prefer.
We hand over what we build
You get the design, the code, the runbook and an app registered to your own account. When you want us to stay, ongoing support is a standing offer. For an example, see how we brought several third-party systems into one Salesforce process.
SurveyMonkey API questions, answered plainly
When survey data has to reach a system no connector covers, such as a data warehouse, a product database or an ERP, or when the flow needs logic, volume, history backfills or error handling that SurveyMonkey for Salesforce, Connect quick actions or a Zapier flow cannot provide. If a connector covers the requirement, it is cheaper to run and maintain, and that is what we recommend.
Every integration starts as a draft app that runs against your own account for 90 days and must then be deployed. A Private app needs no review, but every user must be on the same SurveyMonkey team and on a paid plan with direct API access; it suits an integration for your own organization. A Public app is reviewed by SurveyMonkey and listed in the App Directory; it suits a software vendor connecting many customers' accounts.
Draft and Private apps start at 120 requests a minute and 500 requests a day, reset at midnight GMT, and higher limits can be requested from SurveyMonkey, where fees may apply. Published Public apps can make up to 500,000 requests a day. The limit, the requests remaining and the time to reset come back in response headers, and a breach returns error 1040 as HTTP 429. We design every integration around a request budget rather than hoping to stay under it.
Use webhooks for new and changed responses and the API for everything else. A webhook tells you a response was completed or updated, then the integration fetches the full response once. Polling spends the daily quota on requests that usually find nothing. We add a scheduled reconciliation that reads the bulk responses endpoint by date modified, because SurveyMonkey does not document webhook retries or delivery guarantees.
Every callback is a POST carrying an Sm-Apikey header and an Sm-Signature header, an HMAC-SHA1 digest. The receiver checks the signature before doing anything else and rejects calls that fail. The subscription URL must also answer a HEAD request with HTTP 200 when the webhook is created, and each webhook needs its own unique URL.
Yes. MuleSoft suits organizations that already run it or need the same survey data in several systems. Inside Salesforce, Apex callouts through a Named Credential reach the API, Queueable or Batch Apex handles volume, and an Apex REST endpoint on a Salesforce Site can receive webhooks. For destinations outside Salesforce, a small serverless or Node.js service is often the simplest option. We recommend the runtime your team already operates.
Yes, through their own hosts: api.surveymonkey.com for the US, api.eu.surveymonkey.com for the EU and api.surveymonkey.ca for Canada. The correct host is returned as access_url when the OAuth code is exchanged for a token, and the integration must store and use it for each connection. Requests sent to the wrong regional host are refused.
Next Step
Show us the flow, we will show you the build
Bring the systems involved, the volume and what has gone wrong so far. A first conversation is enough to say whether a connector covers it, which app type and middleware fit if it does not, and what the build would take. No obligation to proceed.
Talk to a Salesforce architect who builds on the SurveyMonkey API
