Product update · Developers
MyKayd Webhooks and API: Connect Form Responses to Your Own Systems
Why MyKayd added webhooks and a public API, who they are for, the problems they solve, and how developers can connect forms and responses to their own software.
Collecting a response is often only the beginning of a workflow. A lead may need to enter a CRM. A support request may need to create a ticket. An application may need to be processed by an internal system. A product team may want form data inside its own dashboard.
Notion and Linear integrations are useful when those are the tools your team already uses. But no form builder can ship a native integration for every internal tool, database, automation, or product a customer might have.
That is why MyKayd now includes webhooks and a public API. They give developers a direct way to connect MyKayd to the rest of their software instead of forcing every workflow through manual exports or a growing list of one-off integrations.
The problem
Form data should not stop at the responses page
A form can be the front door to a much larger process. If the response is trapped inside the form builder, someone eventually has to copy it, export it, poll for changes, or manually move it into the system where the actual work happens.
For a small survey that may be fine. For onboarding, applications, customer intake, product feedback, support, operations, or high-volume workflows, it quickly becomes unnecessary work.
We added developer tools so MyKayd can be the collection and intelligence layer without trying to own every system that comes after it.
Two tools, two jobs
Webhooks: tell my app when something happens
Use a webhook when your system should react immediately after a new MyKayd response is submitted. MyKayd sends the response to your HTTPS endpoint automatically.
API: let my app read MyKayd data
Use the API when your software needs to fetch forms or responses on demand. The first API version is intentionally read-only, so API keys cannot edit or delete your forms or responses.
Webhooks
How MyKayd webhooks work
When a form with an enabled webhook receives a new response, MyKayd creates a response.created event and sends a JSON payload to the public HTTPS endpoint you configured. The payload includes the form, response, submitted answers, and file metadata.
Delivery happens asynchronously, so your respondent does not need to wait for your server before seeing the form's normal completion flow. If your endpoint temporarily fails, MyKayd retries the delivery with increasing delays rather than giving up after the first request.
Each request also includes MyKayd event, delivery, timestamp, and HMAC signature headers. Your server can use the webhook secret to verify that the request was signed by MyKayd before processing it.
POST https://yourapp.com/webhooks/mykayd
X-MyKayd-Event: response.created
X-MyKayd-Delivery: ...
X-MyKayd-Timestamp: ...
X-MyKayd-Signature: sha256=...Set up a webhook
- Open the form you want to connect and go to Integrations.
- Scroll to Developer tools and add your public HTTPS webhook endpoint.
- Save the webhook and keep its signing secret secure on your server.
- Submit a test response and confirm your endpoint receives the response.created event.
- Verify the signature before trusting or processing the payload in production.
Public API
Read your forms and responses from your own application
The MyKayd API is for cases where your application needs to ask for data instead of waiting for an event. You can list forms, retrieve one form, list a form's responses, or retrieve a specific response.
API requests use a Bearer token. Keys begin with mk_live_, are shown only when created, and can be revoked from your MyKayd developer settings. The current API is rate-limited to 100 requests per minute.
GET /api/v1/forms
GET /api/v1/forms/{form}
GET /api/v1/forms/{form}/responses
GET /api/v1/forms/{form}/responses/{response}
Authorization: Bearer mk_live_...Create an API key
- Sign in to MyKayd and open Settings → Developer.
- Give the key a name, such as Production app, and choose Create API key.
- Copy the key immediately. MyKayd does not show the full token again.
- Store it as a server-side secret and send it in the Authorization: Bearer header.
- Revoke the key from Developer settings if it is ever exposed or no longer needed.
Who needs this?
Use integrations for common tools. Use developer tools for your own workflow.
You probably do not need webhooks or the API just to collect a form and read responses in MyKayd. And if your destination is already supported directly, such as Notion or Linear, the native integration is usually the simpler option.
Developer tools become useful when you are building something specific: a SaaS product that consumes form data, an internal operations dashboard, a custom CRM, an applicant-processing system, an automated support workflow, a data warehouse pipeline, or a backend service that needs to react to new submissions.
A useful rule is: use webhooks for events and the API for retrieval. In many production systems, you use both. A webhook tells your application that a response arrived, and the API gives your application a controlled way to retrieve MyKayd data when it needs it.
Why this matters for MyKayd
The form should fit into your system, not become another silo
MyKayd is being built around what happens after someone clicks submit. Response intelligence, Form Watcher, direct integrations, webhooks, and the API are different parts of the same idea: collecting data is useful, but the real value appears when that data can move into action.
We will keep adding direct integrations where they remove setup for common workflows. The API and webhooks are the escape hatch for everything more specific. They let teams keep MyKayd connected even when their workflow is unique.
Building something with MyKayd?
If you are connecting MyKayd to your product, internal system, or automation and need help with the API or webhooks, email us at support@mykayd.com.