SIP Integration

​

Overview

Bland supports inbound SIP termination, allowing customers to direct calls from their SIP provider to Bland for handling.

This guide provides:

• SIP connection details
• Requirements and security settings
• Instructions for attaching, updating, and detaching SIP routes via Bland’s API
• Schema definitions and usage patterns

​

Entitlement Requirement

All /sip endpoints are protected by an entitlement check.

Your organization must have the SIP entitlement enabled to use SIP features. If not, all requests to the /sip routes will return:

{
  "data": null,
  "errors": [
    {
      "error": "SIP_NOT_ENABLED",
      "message": "SIP is not enabled for this organization"
    }
  ]
}

Contact support to have SIP enabled for your Enterprise organization.

​

SIP Termination Details

SIP Signaling Endpoint:

You must use TCP over TLS. Bland does not accept UDP for SIP messages. We do support UDP over S/RTP for media streams. mTLS is not required at this time.

US1:

us1.sip.bland.ai:5061;transport=tls

--
EU1:

Coming Soon

--
AU1:

Coming Soon

Static IP Addresses of the SIP Signalling Server(s):

US1:

35.80.235.26
54.189.4.67

--
EU1:

Coming Soon

--
AU1:

Coming Soon

Static IP Addresses of the Media Stream Server(s):

Bland does not provide static addresses for Media Stream Servers. As part of the SDP negotiation, our SIP Signalling Servers will provide you with the location of an available Media Stream endpoint. Through this, Bland is able to confidently scale our Media Stream capabilities without the need for NAT.

Supported Codecs:

• Currently Supported: PCMU, PCMA
• Coming Soon: Opus, G722

Security Requirements:

• SIP Signaling: TLS 1.2 or higher
• RTP Media: SRTP using AES_CM_128_HMAC_SHA1_80
• From Header FQDN: Bland will enforce validity of the FQDN provided for in your From header. If this should be the same as the signaling endpoint, or a non-valid FQDN, we may reject your request(s) in the future.

Other Configurations:

• RTCP: Uses port RTP + 1

• DTMF: RFC 2833 (Out-of-band via RTP payload)

• Transport: TCP over TLS

• Number Format: +E.164 or E.164 (both supported for origination and termination)

• SIP Registration: Not required (Bland determines routing based on predefined configurations configurable below.)

​

API Reference

​

Attach SIP Endpoint

POST /sip/attach

Attach a SIP configuration to a phone number.

curl -X POST https://api.bland.ai/v1/sip/attach \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+14150000000",
    "directions": [
      { "type": "inbound" }
      { "type": "outbound", "sip_endpoint": "sip.customer.com" } // Either inbound or outbound can be provided
    ],
    "service": "sip"
  }'

​

Update SIP Direction

POST /sip/update

Update a phone number’s SIP routing direction.

curl -X POST https://api.bland.ai/v1/sip/update \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+14150000000",
    "updates": {
      "type": "outbound",
      "sip_endpoint": "sip:user@your.provider.com"
    }
  }'

​

Detach SIP Endpoint

POST /sip/detach

Remove SIP configuration from a number.

curl -X POST https://api.bland.ai/v1/sip/detach \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+14150000000",
    "directions": [
      { "type": "inbound" }
    ],
    "service": "sip"
  }'

​

Get SIP Config

GET /sip?inbound_id={inbound_id}

Returns current SIP configuration (if any) for a given inbound_id.

curl -X GET 'https://api.bland.ai/v1/sip?inbound_id=12345' \
  -H "Authorization: Bearer <token>"

​

Example Response

{
  "data": {
    "phone_number": "+14150000000",
    "directions": [ "inbound" ]
  },
  "errors": null
}

​

Notes

• SIP media handling currently supports inbound-only termination.
• Phone numbers can be attached independently for inbound and outbound routing via the API.
• All requests must conform to the expected schema; invalid payloads will be rejected with a 400 response.
• Each API response includes a success status and, if applicable, an error message to aid debugging.