Triggering surveys from your own system

The Send Survey API lets your own system trigger a survey — when a job completes, a ticket closes, a contract renews, or anything else your software knows about that we don’t.

API access is an Agent Enterprise feature. It isn’t included on Free, Agent Pro or Agent Advanced — see plans and pricing.

It’s a focused tool, not a general-purpose data API. To read your feedback programmatically, use the MCP server instead.

Set it up

API access is configured as a skill, not on a separate developer screen.

1. Go to Settings → Skills Marketplace (or Active Skills if you’ve set it up before).
2. Find Send Survey API — A flexible tool for your tech team to trigger surveys from any custom system or app you already use.
3. Connect or Configure to open Configure API.

Create an action

An action ties a key to what should happen when it’s called:

• Connected Survey — which survey to send
• Channel — how it’s delivered
• Trigger delay (hours) — how long to wait after the call before sending
• API Key Name — naming a key here creates it

Create Action saves it.

The trigger delay is worth using. Your system usually knows about the event immediately, but immediately is rarely the right moment to ask — a delay of a few hours or days lets you fire the call when it happens and still ask when it makes sense.

Managing keys

Under Available API Keys — Manage integrations and authentication tokens:

• Generate Key creates another, named (e.g. Production Integration)
• Expanding a key reveals its Bearer Token with a copy button, and a ReactJS Fetch Example you can adapt
• Revoke Key in the Danger Zone kills it immediately

Keys show as Active, Inactive, Expired or Revoked.

Calling it

POST to your organisation’s webhook URL with the key as a bearer token, sending the customer’s email, name, and the survey_id. The example in the modal shows the exact shape — copy it from there rather than from documentation that could drift.

Treat keys as credentials

• Store them in environment variables or a secrets manager, never in source code
• Never commit them, public repo or private
• Never send one to us or anyone else — we will never ask for a key
• Use a separate key per integration so one can be revoked without breaking everything
• Rotate if you suspect exposure

→ Security and acceptable use

Build for failure

Queue and retry rather than dropping. A feedback event you fail to send is gone — and unlike most integrations, nobody notices for weeks.

Check these first

Plenty of things people plan to build with the API already exist:

• Getting customers in — import a list or a direct integration
• Reacting to events — automations already handle Shopify, Stripe and Cin7 events, plus generic webhooks
• Asking questions of your data — the MCP server

Check those before writing code.