You have a fraud ticket open. Your team wants to check whether a customer's SIM was recently swapped before you let a high-value transfer through, and the plan is to use Infobip's Connectivity API. Someone suggests an agent could read the contract and wire it up for you. Before that happens, it helps to know what the contract actually says, and that is what a recent APIs.io post sets out.
Start with the scale. 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. The contract has 36 operations and 7 webhooks. The record lists an OpenAPI 3.2.0 document, 6 JSON Schemas, and documentation and API reference links, and 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.
Now the first thing you will trip over. There are two SIM swap paths: 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 to you.
Then you look at the lookups. 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 what a code generator needs.
You may also worry about permissions, since the verbs split 22 POST, 10 GET, 4 DELETE. The post's phrasing overlay covers 34 operations and marks 22 as reads, and 12 of those are POSTs, because 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.
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. If your security review wants least privilege, the contract gives you nothing to point to.
The post also turns the lens on the catalog's own record. The 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. The post says those links should be scoped to this API. So if you followed the record's docs links looking for guidance on SIM swap, you could have landed on material about other products entirely. That one is the catalog's fix to make, not Infobip's.
What you take away is balanced. The post's verdict is that this contract describes a hard domain well, with typed sessions and named result webhooks. For your fraud check, though, you should settle two things before any code is generated: which SIM swap path you will call, and what shape the number context report takes, since the spec will not tell you. Both are fair questions for your Infobip account manager. The post says that if Infobip gave the number context report a webhook and named a canonical SIM swap path, the API would get noticeably easier for an agent to use.
Read the original: https://apis.io/2026/11/02/infobips-connectivity-api-offers-sim-swap-twice-and-its-async-lookup-has-no-webhook-contract/