Bharti Airtel · AsyncAPI Specification

Bharti Airtel Webhooks

Version

View Spec View on GitHub TelecommunicationsIndiaMobile Network OperatorNetwork APIsCAMARAOpen GatewaySIM SwapCPaaSMessagingSMSRCSVoiceIoTM2MDevice LocationBroadband5GIdentity VerificationCarrier BillingConsent ManagementAsyncAPIWebhooksEvents

AsyncAPI Specification

Raw ↑
generated: '2026-07-25'
method: searched
source: >-
  openapi/bharti-airtel-locate-openapi.yml, openapi/bharti-airtel-iq-reporting-openapi.yml and
  https://www.airtel.in/webcms/content/card/name/airtel-iq-documentation (HTTP 200)
spec_type: Webhooks
asyncapi_published: false
asyncapi_note: >-
  No AsyncAPI document is published for any Airtel event surface. /asyncapi.yaml and /asyncapi.json
  return 404 on openapi.airtel.in and m2m.airteliot.co.in, and return HTTP 200 with the 8,991-byte
  Angular SPA HTML shell (text/html) on www.airtel.in — a soft 404, not a specification. The webhook
  catalogue below is the real event surface, captured from Airtel's own documentation and
  specifications. NOTHING here is fabricated: where Airtel does not publish a payload schema, the
  schema field is null.
direction: >-
  Every Airtel event surface is INBOUND-TO-THE-CUSTOMER: Airtel POSTs to an endpoint the enterprise
  builds and registers with Airtel. There is no subscription API, no event catalogue, no signature
  scheme and no delivery-retry contract published anywhere in the estate.
webhooks:
  - name: locate.location.async
    api: locate
    product: Airtel Locate
    trigger: >-
      A location request made with type=async
      (openapi/bharti-airtel-locate-openapi.yml#getLocationUsingGET_3 or
      #getLocationForTenantsUsingGET_1). Airtel returns 202 with an AsyncCorrelationId and later
      POSTs the resolved location to the customer's registered callback listener.
    correlation_field: correlationId
    registration: >-
      "Customer need to register the callback listener for the async API where Locate would post
      the location." Registration is performed out of band; no registration API is published.
    failure_mode: >-
      HTTP 403 on the location request with "callback url is not registered" — a documented,
      first-class error state.
    payload_schema: openapi/bharti-airtel-locate-openapi.yml#/components/schemas/LocationResponse
    payload_note: >-
      The specification defines LocationResponse (location.latitude/longitude, status, message,
      retrievedAt) for the synchronous 200. Airtel does not publish a separate schema for the
      asynchronous callback body.
    signature: null
    retry_policy: null
  - name: iq.voice.cdr
    api: iq-reporting
    product: Airtel IQ Voice
    trigger: Completion of an inbound or outbound call placed through an Airtel IQ Intelliphone.
    registration: >-
      "the Integrator endpoint for receiving CDR can either be preconfigured at Airtel IQ end or
      can be passed in the callBackURLs in callFlowConfiguration of execute callflow Api."
    payload_schema: openapi/bharti-airtel-iq-reporting-openapi.yml#/definitions
    payload_note: >-
      Airtel ships a reference implementation of the customer side rather than a schema for its own
      sender: POST /sampleCdr (#postSampleCdrUsingPOST) is "a sample API to test the CDR
      integration of Integrator with Airtel IQ. The Integrator needs to develop a post API similar
      to this API, on which all these details would be posted." The CDR carries Time, Date,
      Duration, Caller_ID, Destination_Number, Status and the call-recording URL.
    signature: null
    retry_policy: null
  - name: iq.voice.incoming-call
    api: iq-voice
    product: Airtel IQ Voice (inbound call flows)
    trigger: An inbound call landing on an Intelliphone.
    registration: >-
      "Enterprise shares API endpoints with Airtel IQ on which details of the incoming call will be
      posted. Airtel IQ posts the call information as soon as the call lands on the Airtel IQ
      platform." The call-flow components incomingCallParameters (pass callbackURLs and metadata)
      and incomingCallAction (accept/reject/redirect) drive this exchange.
    bidirectional: true
    bidirectional_note: >-
      Case 2 of the documented inbound patterns inverts the relationship entirely — Airtel calls
      the ENTERPRISE'S API mid-call to fetch call-flow configuration (destination number, audio
      URLs) while the call is live. The enterprise is the API provider in that exchange.
    payload_schema: null
    signature: null
    retry_policy: null
  - name: iq.sms.delivery-report
    api: iq-sms
    product: Airtel IQ SMS
    status: referenced-not-specified
    note: >-
      Delivery reports are referenced in Airtel's SMS product marketing ("delivery reports" is a
      target keyword on https://www.airtel.in/b2b/sms-api) and DR is an enumerated consent-event
      type in the Locate consent lifecycle, but no delivery-report callback contract, payload or
      registration mechanism is published in openapi/bharti-airtel-iq-sms-openapi.yml or in the
      Airtel IQ documentation. Recorded as referenced, not as a specified webhook.
    payload_schema: null
counts:
  webhooks_specified: 3
  webhooks_referenced_only: 1
  asyncapi_documents: 0
gaps:
  - No signature or authentication scheme is published for any Airtel callback.
  - No delivery retry, ordering or at-least-once guarantee is documented.
  - No webhook registration API exists; every listener is registered out of band.
  - No event catalogue or subscription surface exists for any Airtel product.