sip_trunk.not_found

Summary

sip_trunk.not_found means the active workspace has no SIP trunk connected. It is returned by GET, PUT and DELETE /v1/sip-trunk — the workspace's own trunk is a singleton, so there is no ID to get wrong. On GET and DELETE it means what it says: call one of those endpoints before ever connecting a trunk, or after disconnecting it. On PUT it is rarer and means something more specific — see Cause below.

Cause

A workspace's own SIP trunk is a single row, keyed to the workspace, not a collection of trunks with IDs. GET and DELETE read or remove that row and fail when it does not exist. PUT upserts it, so this is rare on PUT — it only shows up as a narrow race: after the trunk row is written, a registration trunk's PUT reads the credential back to push it to the box and poll for registration. If a concurrent DELETE /v1/sip-trunk removes the row in the window between that write and the read-back, the read-back finds nothing and the in-flight PUT fails with sip_trunk.not_found even though it just committed the row itself.

Resolution

Connect a trunk first:

curl -X PUT "https://api.sautikit.com/v1/sip-trunk" \
  -H "Authorization: Bearer $SAUTIKIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Head office trunk",
    "auth_mode": "registration",
    "proxy": "sip.example-carrier.com",
    "transport": "udp",
    "username": "sautikit_100",
    "password": "…"
  }'

If you expected a trunk to already exist, GET /v1/sip-trunk is the fastest way to check what, if anything, is connected. If this came back from a PUT, don't run a DELETE and a PUT against the same workspace's trunk concurrently — serialize the two, or simply retry the PUT.

Example response

{
  "error": {
    "code": "sip_trunk.not_found",
    "message": "no SIP trunk is connected to this workspace",
    "request_id": "req_01900000abc"
  }
}

Next steps

• Numbers concepts — bring your own SIP trunk
• numbers.byo_requires_trunk — the same "no trunk yet" state, seen when adding a number instead