---
name: provision-number-and-wire-up-webhooks
description: Search, purchase and configure an Infobip number, then attach the SMS/MMS/voice inbound configuration
  and webhook endpoints that route traffic back to you.
api: openapi/infobip-numbers-openapi.json
operations:
- get-available-numbers
- purchase-number
- list-owned-numbers
- create-new-configuration
- create-mms-configuration
- create-voice-setup-on-number
- update-owned-number
provider: Infobip
generated: '2026-07-25'
method: generated
source: Grounded in operationIds verified in openapi/infobip-numbers-openapi.json plus conventions/infobip-conventions.yml,
  errors/infobip-error-codes.yml and rate-limits/infobip-rate-limits.yml
---

# Provision a number and wire up its webhooks

Search, purchase and configure an Infobip number, then attach the SMS/MMS/voice inbound configuration and webhook endpoints that route traffic back to you.

## Ground rules for every Infobip call

- Base URL: `https://api.infobip.com` (an account may also be issued a personalized `https://{subdomain}.api.infobip.com` host shown in the web portal — either works).
- Auth header: `Authorization: App {API_KEY}`. Basic auth is only for the API-key-management endpoints. Every endpoint additionally requires at least one API scope (see `scopes/infobip-scopes.yml`).
- There is **no idempotency key**. Never blind-retry a send on a timeout or 5xx — re-read the outcome with the reports/logs operation for the returned `bulkId`/`messageId` first (`conventions/infobip-conventions.yml`).
- On `429` back off exponentially and honour `Retry-After`. Per-operation limits are published in the spec as `x-throttling-info` and collected in `rate-limits/infobip-rate-limits.yml`.
- HTTP errors use the Infobip `requestError.serviceException {messageId, text, validationErrors}` envelope (not RFC 9457) — see `errors/infobip-problem-types.yml`.
- A `200` does **not** mean delivered. Message outcome lives in the `status {groupId, groupName, id, name}` and `error {groupId, groupName, id, name, permanent}` objects; resolve them against `errors/infobip-error-codes.yml`. `permanent: true` means a retry can never succeed.
- Listing endpoints page with `page`/`size` (max 100) and return `{page, size, totalPages, totalResults}`; newer endpoints support `cursor`/`useCursor`.

## Steps
1. **Search inventory** — `get-available-numbers` (`GET /numbers/1/numbers/available`) filtered by `country`, `capabilities` and `type`. Keep the `numberKey`.
2. **Purchase** — `purchase-number` (`POST /numbers/1/numbers`). This is a billable, non-idempotent write: if the call times out, call `list-owned-numbers` (`GET /numbers/1/numbers`) and check before retrying.
3. **Configure inbound SMS** — `create-new-configuration` (`POST /numbers/2/numbers/{numberKey}/sms`) with the keyword/`notifyUrl` routing you want; `list-configurations-for-number` and `modify-sms-configurations` manage it afterwards.
4. **Configure MMS and voice** — `create-mms-configuration` (`POST /numbers/2/numbers/{numberKey}/mms`) and `create-voice-setup-on-number` (`POST /numbers/2/numbers/{numberKey}/voice`); `update-cnam` sets the caller name where supported.
5. **Verify the endpoint before you rely on it.** The Subscriptions Management API exposes a test-connection-to-webhook operation, and every callback Infobip can send is catalogued in `asyncapi/infobip-webhooks.yml`. Secure the endpoint with a bearer token, basic auth or a message signature, and dedupe on the payload's event identifier — Infobip retries.
6. **Release** — `cancel-number` (`DELETE /numbers/1/numbers/{numberKey}`) stops the recurring charge.