The Infobip Connectivity API is the telecom identity layer of Infobip: number lookups, silent mobile verification, SIM swap checks, national ID checks, biometric sessions, and CAMARA endpoints. Its contract has 36 operations and 7 webhooks. It also carries two different SIM swap paths, and one asynchronous lookup whose result has no defined shape in the spec.
What ships
The record lists an OpenAPI 3.2.0 document, 6 JSON Schemas, and documentation and API reference links. The OpenAPI file itself defines 94 component schemas. Infobip the provider scores 81.8 (exemplar) on the Kin Score and 52.3 on Agent Readiness, band agent-ready, gated down from agent-native. This API is one of six the record lists for the provider.
| Surface | Example path | Operations |
|---|---|---|
| Number lookups and reports | /number/1/query |
5 |
| Silent verification and intelligence | /mi/verification/1/verify |
8 |
| Biometric sessions | /biometrics/1/kyc/sessions |
13 |
| CAMARA | /camara/sim-swap/v0/check |
10 |
The verbs split 22 POST, 10 GET, 4 DELETE. The method count hides what the operations do. Our phrasing overlay covers 34 operations and marks 22 as reads, and 12 of those are POSTs, since they take phone numbers and national IDs in the body. An agent that treats POST as a write will ask for permission it does not need. An agent that reads the overlay will not.
The same check, two contracts
POST /mi/simswap/1/check and POST /camara/sim-swap/v0/check both answer whether a SIM swap happened for a number within a period. They share the summary “SIM Swap” and nearly the same description. The first adds a warning: “API and URL may vary per country. Contact your Account Manager for implementation details.” The CAMARA path carries no such caveat. Number verification has the same layering, with v0 and v2 side by side under /camara/number-verification/. Nothing in the spec says which path Infobip prefers, so that decision falls on the integrator.
The async gap
POST /number/1/notify is documented as receiving number context information “at some endpoint asynchronously.” It responds 200, not 202, and defines no callbacks object. The 7 webhooks cover silent verification, advanced verification, number intelligence, and the four biometric session types. None of them is the number context report. So the one lookup explicitly built around a callback is the one where the spec does not describe what arrives. Silent verification, by contrast, gets a named webhook for its result, which is exactly what a code generator needs.
Authentication is more generous than usual. 35 of 36 operations accept any of four schemes: OAuth2, API key header, IBSSO token and Basic. The exception is GET /camara/number-verification/v0/authorize, which declares none. The OAuth2 scheme defines only a client credentials flow with no scopes, so a token cannot be narrowed to lookups only in anything the contract states.
One fix is ours. The record’s humanURL points at the 2FA docs page, and its properties repeat 47 documentation and reference pairs from across the whole Infobip platform, including AI Hub and channel pages. Those links should be scoped to this API.
Takeaway
This contract describes a hard domain well, with typed sessions and named result webhooks. Give the number context report a webhook, say which SIM swap path is canonical, and it gets noticeably easier for an agent to use. Read it on the Infobip Connectivity API page.