From your first event
to a working workflow.
Preview — the API and webhooks are built, but access is still disabled. Use this guide to plan your workflow; connection setup opens after activation.
1. Send a lead
Set ACTIONMODE_URL to your installation’s origin and ACTIONMODE_KEY to your connection key. Generate a UUID once for REQUEST_ID and save it with the source event. Reuse it and the same body for retries.
cURL example
A new request returns 202 with an id and status_url. This means the event is saved, not finished. The worker checks the queue every minute. Small queues usually start on the next tick; retries and backlog can take longer.
Poll example
Poll every 5–10 seconds until status is succeeded or failed. A successful lead receipt contains result.lead_id. Use that ID for a note or draft request, with a new request UUID.
2. Choose the work
| Event | Data | Permission |
|---|---|---|
| lead.upsert | external_id, name; optional company, role, email, website | leads.write |
| note.add | lead_id, body | notes.write |
| reply.received | outreach_id, from_email, body; optional subject, message_id | replies.write |
| outreach.requested | lead_id, brief | drafts.write |
Wrap fields as { "type": "event.name", "data": { ... } }. Lead intake matches the connection’s external ID, then an unambiguous project email, and fills empty fields. It preserves existing nonempty fields and lifecycle state. Notes do not automatically request a draft. Reply intake requires a sent ActionMode message and its lead’s sender address.
Draft requests respect the existing in-flight, pending-draft, niche-research and budget checks. A successful receipt identifies the run; it does not promise a finished draft. Inspect the run or listen for draft-ready events. Review and approve in ActionMode.
3. Receive signed webhooks
Create a public HTTPS receiver before adding its URL to a connection. Choose the events you need and save the one-time signing secret. Receivers must acknowledge with a 2xx response within 8 seconds.
Verification recipe
Read the X-ActionMode-Signature and X-ActionMode-Event-Id headers. The body contains id, type, version, project_id, occurred_at and data. Events contain record IDs, not message bodies. Use data.read permission to fetch details when needed.
Available events: lead.created, reply.received, outreach.draft_ready, run.succeeded and run.failed. Delivery is at least once, can arrive out of order and retries up to five total attempts. Network failures, 408, 429 and 5xx responses retry. Redirects and other 4xx responses fail without retry.
Read the result
- GET /api/v1/events/RECEIPT_ID — this connection’s receipt; no extra read scope required.
- GET /api/v1/leads?limit=25&after=CURSOR — lead list with next_cursor, maximum 100 per page.
- GET /api/v1/leads/ID, /outreach/ID, /replies/ID or /runs/ID — project-scoped detail, requires data.read.
List cursors sort by ID, not creation time. Webhooks report a change; detail reads show the current state. Keep keys on a server, never in public browser JavaScript.
Limits and recovery
- 60 requests per minute per key, including receipt polls. 429 includes Retry-After: 60.
- 32 KiB maximum request body; 100 unfinished incoming events per connection; 10 active connections per project.
- 401: check expiry or revocation. 403: check permissions. 409: the request UUID was reused with different content. 503: retry the same UUID and body.
- record_unavailable: check the lead and project. record_write_failed: resolve ambiguous email matches or invalid data before submitting a corrected event.
- draft_plan_required: restore plan access. draft_budget: the project ceiling blocked the draft. draft_duplicate or draft_inflight: inspect Comms and current runs. draft_researching: wait for niche research to finish.
- reply_sender_mismatch or sent_outreach_required: correct the source-to-outreach mapping. Do not turn an unmatched email into an assumed reply.
- Delivery failed: check the receiver and its response. In this release, exhausted deliveries have no replay button. Reconcile the underlying records through the API; create a fresh event only for a new or corrected command.
Keys expire after 90 days. Create a replacement, update the workflow, then revoke the old connection. Revocation stops new requests and queued work; work already running may finish. Settings shows the latest 20 incoming and outgoing records; refresh for updates.
Connect through your workflow builder
In n8n use a source trigger and HTTP Request nodes. In Make use the source module and HTTP request module. In Zapier use a trigger and Webhooks / custom request step where your plan supports it. Map the fields, persist a request UUID, send the POST, then poll its receipt before using its returned IDs. Outgoing webhooks need a receiver that verifies raw-body signatures.
These are HTTP recipes. Provider subscriptions and automation usage are billed by those services. This release adds no native CRM OAuth, continuous two-way sync, payment actions or external MCP client inside ActionMode.