Event Notifications

Event notifications let you react to things happening inside Superfone — calls completing, recordings becoming available, AI summaries finishing, leads being created or updated, tasks being scheduled — by having Superfone POST an event payload to a URL you control.

Each notification is bound to one event and one destination URL. When the event fires for an account, Superfone enriches the payload with related contact / call / task data and delivers it to the configured URL with the headers you set.

How it works

Configuration

Dashboard-only management

All management of event notifications — creating, editing, enabling, disabling, and deleting — happens exclusively in the Superfone dashboard's Automations page. There is no API for managing notifications programmatically.

You can configure multiple notifications per event — each one fires independently.

Available events

Event	Fires when
ALL_CALLS	A call completes and the CDR is finalized — fires for every call (inbound and outbound).
MISSED_CALL	A call ends without being answered.
CDR_RECORDING_AVAILABLE	A call recording is uploaded to storage and a downloadable URL is available.
CDR_SUMMARY_READY	The AI-generated summary and/or transcription for a call recording is ready.
CUSTOMER_CREATE	A new lead is created in your CRM (any source — manual, import, integration webhook, AI agent).
CUSTOMER_CHANGE	A field on an existing lead changes (first_name, last_name, labels, phones, lead_stage, lead_group, assignee_user, source, source_type, city).
TASK_CREATE	A new task is created against a lead.
TASK_CHANGE	A task's task_type, task_status, or task_due_date is updated.
TASK_NOTIFY_TIME	The notify time for a task is reached (e.g. 10 minutes before due).
TASK_DUE_TIME	A task's due time is reached.

See Payload reference for the JSON shape of each event.

Delivery semantics

• Method: POST.
• Body: JSON. Common envelope is described in Payload reference.
• Headers: Content-Type: application/json plus any custom headers you configured.
• Success: Any HTTP status < 400 is treated as success. Anything >= 400 is logged as a failure.
• Retries: Failed deliveries are not retried automatically. Plan your endpoint to be tolerant — return 2xx as soon as you've durably accepted the payload, then process asynchronously.
• Timeout: Default HTTP client timeout (~axios default of no timeout — keep your handler fast; aim for under 5 seconds).
• Order: Events are processed in the order Superfone receives them, but cross-event ordering across different event types is not guaranteed. Don't assume CUSTOMER_CREATE lands before TASK_CREATE for the same record.

Securing your endpoint

Superfone does not sign request bodies (no built-in HMAC). To verify a request really came from Superfone:

1. Don't put the raw URL in client-side code.
2. Set a static auth header. Configure something like Authorization: Bearer <random-secret> in action_config.headers. Verify the header on every incoming request and reject anything missing or wrong.
3. Always use HTTPS. Plain HTTP URLs leak your custom auth header in transit.

Filtering events

You can narrow down which events actually trigger a delivery — for example, only fire for outbound calls over 30 seconds, or only for leads from a specific source. Create and manage filters from the Superfone dashboard via our Automations Feature alongside the URL and headers for each notification.

Observability

Every notification delivery — including failures — is logged against the action setting in the logs section of Superfone dashboard via our Automations Feature. The activity record contains:

• event_payload — The internal event payload that triggered this delivery
• body — The exact JSON Superfone sent to your URL
• response — Your endpoint's response body (on success) or error (on failure)
• group_id_ref — A correlation ID. Quote this when contacting Superfone support about a specific delivery.

Next steps

• Payload reference — Full schema of the JSON Superfone sends, including per-event extras