HTTP API

Three endpoints, served on SIP_HTTP_PORT (default 8082). Only /sip/originate is authenticated.

GET /health

curl -s http://148.113.58.51:8082/health

{ "status": "ok", "service": "sip-sfu-gateway" }

Always 200 while the process is serving. It says nothing about the SIP leg or the routing store — see observability for a check that covers both.

GET /calls

Every call currently bridged, oldest first.

curl -s http://148.113.58.51:8082/calls

{
  "live": [
    {
      "to_number": "+919363399639",
      "from_number": "+13187184515",
      "name": "sip-module",
      "sip_call_id": "3e114ad4-a9ad-4a0b-97b9-5cf11190bdd8",
      "session_id": "527f78a3262dbe8b0d0a678a9e98ac29",
      "project_id": "fa3f23f8-a75d-44a4-84f0-6a1c828f579f",
      "direction": "outbound",
      "source": "originate",
      "started_at": "2026-09-21T10:14:52.118Z"
    }
  ]
}

The list is sorted rather than map-ordered, so polling it does not reshuffle rows on every request.

POST /sip/originate

Places one outbound call. Authenticates with a control-plane API key, and the room opened for the call belongs to the project that key identifies — which is how one gateway serves several projects without per-project configuration.

curl -X POST http://148.113.58.51:8082/sip/originate \
  -H 'Authorization: Bearer ulai_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
    "to_number":        "+919363399639",
    "trunk_id":         "74958094-8c76-419f-aa42-d4eac6768ec2",
    "project_id":       "fa3f23f8-a75d-44a4-84f0-6a1c828f579f",
    "from_number":      "+13187184515",
    "name":             "sip-module",
    "max_participants": 8,
    "offer_srtp":       true,
    "require_srtp":     true,
    "dial_verbatim":    false,
    "session_id":       "527f78a3262dbe8b0d0a678a9e98ac29"
  }'

The smallest request that works — the gateway creates the room and infers SRTP policy from the trunk’s transport:

curl -X POST http://148.113.58.51:8082/sip/originate \
  -H "Authorization: Bearer $ULAI_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "to_number": "+919363399639",
    "trunk_id":  "74958094-8c76-419f-aa42-d4eac6768ec2",
    "project_id":"fa3f23f8-a75d-44a4-84f0-6a1c828f579f"
  }'

Request body

Bodies are capped at 8 KiB. Validation reports every problem at once, so a dialler does not get one complaint per round trip.

202 Accepted

{
  "status": "originating",
  "to_number": "+919363399639",
  "session_id": "527f78a3262dbe8b0d0a678a9e98ac29",
  "created": false,
  "name": "sip-module",
  "trunk": "Main SBC"
}

created says whether the gateway made the room (and is therefore responsible for tearing it down). The response returns as soon as the trunk is resolved and the room exists — the phone is still ringing. Point an agent or a browser at session_id while it does; the gateway itself joins the room only once the callee answers.

Errors

{ "error": "to_number is required\ntrunk_id is required" }

A 404 means the request asked for something that is not there; a 502 means an upstream failed. Only one of those is worth retrying.

What happens next

Nothing else comes back over HTTP. The call’s progress shows up in three places:

• The log, prefixed with the number.
• GET /calls, once the bridge starts.
• Telecom events — CALL_ANSWERED then CALL_HANGUP, published to the platform’s stream. See routing.

If the callee never answers, the room created for the call is terminated rather than left running.