Telecom

Give a recipient a SIP line

Hands a recipient an internal SIP line so voice alerts can reach them, and mirrors the line into their internal_sip contact in the same step — call routing reads the contact, not the line, so a line without the contact rings nowhere. Has side effects outside this system: it writes PJSIP records into the telephony switch and asks it to reload, and provisioning a brand-new line also wires an inbound number to it — a number the company already owns and has free, or failing that a fresh one from the shared pool. Idempotent per recipient: a recipient who already holds a line gets that same line back and the answer is 200 instead of 201, so a retry after a timeout never produces a second line. 201 means a line was newly provisioned; 200 means an existing one was reused or bound. Rate-limited in step with the dashboard, because every call reloads the switch.

post/api/v1/extensions

Request

  • Base URL: https://wardenpoint.com (the document declares no server; this is the origin it was published from)
  • URL: https://wardenpoint.com/api/v1/extensions
  • Auth: API key in header X-API-Key

Request body

recipient_uuidstring uuid required

Who gets the line. Must belong to the same company as the key.

extension_uuidstring uuid nullable

An existing free line of the company to hand over. Omit to have a new line provisioned instead. Three cases differ: a free operator line of this company is bound (200); a line of this company that somebody already holds, or that is not an operator line, answers 422; a UUID belonging to another company is treated as omitted and a new line is provisioned. Ignored entirely when the recipient already holds a line — that line is returned instead.

Response

The recipient already had a line, or an existing free line was bound. Same body as 201.

Example response

{
  "data": {
    "extension": "1001"
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.