Inmobi Authentication

generated: '2026-08-12'
method: searched
source: >-
  https://support.inmobi.com/monetize/inmobi-apis/reporting-api ,
  https://support.inmobi.com/monetize/inmobi-apis/ad-management-api/authentication-and-request-protocol ,
  https://support.inmobi.com/dsp/global/inmobi-dsp-global/reporting-for-inmobi-dsp-global/cost-api-integration-for-inmobi-dsp
notes: >-
  InMobi publishes no OpenAPI, so this profile is read from the provider's own
  API reference pages and confirmed against live unauthenticated probes of each
  host. Three distinct authentication schemes are in play across three
  independently versioned APIs — there is no single InMobi auth model. All
  schemes are custom header / bearer-token designs; InMobi documents no OAuth 2.0
  authorization server, no OIDC discovery document, and no scope vocabulary.
summary:
  scheme_count: 3
  oauth2: false
  openid_connect: false
  mutual_tls: false
  api_key: true
  bearer_token: true
  session_token: true
  discovery_document: false

schemes:
- id: publisher-reporting-session
  api: InMobi Publisher Reporting API 3.0
  type: apiKey
  in: header
  style: two-step-session
  docs: https://support.inmobi.com/monetize/inmobi-apis/reporting-api
  credentials:
  - name: userName
    location: header
    description: Account email address registered on the InMobi publisher platform.
  - name: secretKey
    location: header
    description: API key generated from the InMobi publisher dashboard.
  - name: accountId
    location: header
    description: InMobi account identifier.
  - name: sessionId
    location: header
    description: Session token returned by the session-generation call; may exceed 1000 characters.
  session:
    endpoint: https://api.inmobi.com/v1.0/generatesession/generate
    method: POST
    request_headers:
    - userName
    - secretKey
    validity: 8 hours from issuance
    max_sessions: 15 per 8-hour window per API key
  evidence:
    probed: '2026-08-12'
    url: https://api.inmobi.com/v3.0/reporting/publisher
    method: POST
    http_status: 400
    body: '{"error":true,"errorList":[{"code":1004,"message":"Secret Key is missing"}]}'
    note: >-
      Unauthenticated POST is rejected with the documented error code 1004,
      confirming the secretKey header is the enforced credential. A POST to the
      documented session endpoint https://api.inmobi.com/v1.0/generatesession/generate
      returned HTTP 404 with a JSON error envelope on 2026-08-12 — the host routes
      the path but the documented generatesession route did not answer, which may
      mean the documentation is ahead of or behind the deployed route.

- id: ad-management-static-headers
  api: InMobi Ad Management API
  type: apiKey
  in: header
  style: static-header-triplet
  docs: https://support.inmobi.com/monetize/inmobi-apis/ad-management-api/authentication-and-request-protocol
  credentials:
  - name: x-client-secret
    location: header
    description: API key generated from the InMobi publisher platform (same key issuance flow as the Reporting API).
  - name: x-account-id
    location: header
    description: Account ID, found under Payment Settings on the Finance tab of the InMobi platform.
  - name: x-client-id
    location: header
    description: Email address of the account.
  transport: https only (stated in the provider docs)
  evidence:
    probed: '2026-08-12'
    url: https://publisher.inmobi.com/rest/api/v2/apps
    method: GET
    http_status: 401
    body: '{"error":true,"errors":[{"errorCode":"[ERROR_MISSING_HEADERS]","reason":"[x-account-id] header is missing"}]}'
    note: >-
      Anonymous GET names the missing header explicitly; supplying placeholder
      values for all three headers returned 401
      {"errorCode":"AUTHENTICATION_ERROR"} — the triplet is enforced server-side.

- id: dsp-cost-bearer-token
  api: InMobi DSP Cost API
  type: http
  in: header
  style: bearer-token
  docs: https://support.inmobi.com/dsp/global/inmobi-dsp-global/reporting-for-inmobi-dsp-global/cost-api-integration-for-inmobi-dsp
  credentials:
  - name: Authorization
    location: header
    description: Token issued by the token endpoint; sent as the raw token value per the provider docs.
  token_endpoint:
    url: https://api.cdr.inmobi.com/api/v3/auth/token
    method: POST
    grant_inputs:
    - clientId
    - clientSecret
    validity: 8 hours
  evidence:
    probed: '2026-08-12'
    url: https://api.cdr.inmobi.com/api/v3/auth/token
    method: POST
    http_status: 400
    body: '{"status":"FAILED","code":400,"error":{"code":"client.cred.invalid","message":"The provided credentials are invalid. Please check your clientId & clientSecret and try again."},"message":"Request Processing Failed."}'
    note: >-
      Live token endpoint. Uses a client-credentials SHAPE (clientId /
      clientSecret) but is NOT an OAuth 2.0 token endpoint — the response is a
      custom envelope, not an RFC 6749 token response, and no
      /.well-known/oauth-authorization-server is served on this host (403).

unauthenticated_surfaces:
- api: InMobi Server-to-Server Ad Request API 3.1
  url: https://api.w.inmobi.com/showad/v3.1
  note: >-
    Ad-serving endpoint. No credential header is documented; the caller is
    identified by an InMobi Property ID carried in the request payload. An
    anonymous GET and POST both returned HTTP 204 on 2026-08-12 (live host,
    no ad returned for an empty request).

gaps:
- no OAuth 2.0 or OpenID Connect authorization server
- no /.well-known/openid-configuration or /.well-known/oauth-authorization-server on any InMobi host (all 404 or 403 — see well-known/inmobi-well-known.yml)
- no documented scope or permission vocabulary; access is account-wide per API key
- no documented key-rotation or key-revocation API
- three different header conventions across three APIs (secretKey vs x-client-secret vs Authorization)