Get access

Get started · 10 / 42

Hangup, and what happens next

POST /v1/calls/end returns 204 once the interaction is committed durably. A later POST /v1/recall_and_enrich for that caller normally returns the call but can lag, so verify with a later controlled recall.

Submit what happened after the call ends:

curl -i -sS -X POST https://mcp.northsun.ai/v1/calls/end \
  -H "Authorization: Bearer $NORTHSUN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+15551234567",
    "session_id": "call_demo_01",
    "transcript": [
      { "role": "user", "text": "Please call me Tuesday morning.", "ts_ms": 0 },
      { "role": "agent", "text": "I will record that callback request.", "ts_ms": 2400 }
    ],
    "duration_s": 18,
    "outcome": "callback_requested"
  }'

A successful request returns 204 No Content, with no body. Call it once after hangup, using the same phone_number and session_id you used on recall.

What the 204 confirms

The interaction is committed durably. calls/end writes the interaction before it responds, so if that write fails the request itself fails instead of acknowledging a call that was never recorded. The 204 is an acknowledgement of that durable write, not a receipt for a separate downstream process you need to poll.

What a later recall does

A later recall_and_enrich for the same caller normally returns this call. It may lag: a recall that was already in flight when the call ended, or a cached entry that has not refreshed yet, can still return the earlier state. Do not build logic that depends on the very next recall already containing this call.

Verify with a later controlled recall. Use a controlled test caller, call recall_and_enrich again with a new session ID, and check that the history includes the call. If it does not appear yet, repeat the recall after a short, bounded interval; do not re-submit calls/end to force it. Retain the trace IDs, UTC timestamps and redacted session IDs, and follow Troubleshooting if it still does not appear.

Retries and duplicates

If your platform's webhook delivery is unreliable and retries deliveries, deduplicate by your own call identifier before calling calls/end again. See Errors, rate limits, and retries.

What this does not promise

  • It does not promise that the next recall already includes this call. The durable write is the guarantee; visibility in a later recall is verified, not assumed.
  • It does not promise that enrichment (person/company/phone lookups) is complete by the next recall; that pipeline is separately asynchronous by design. See What recall gives you back for how it stays independently nullable.
  • It does not change the 204 response itself: there is no body to parse.
  • It applies to the caller-memory path documented here. It is not a latency benchmark and does not change the public latency language, which stays designed for sub-300ms voice recall.

Next steps