Madvertise Authentication

generated: '2026-08-12'
method: searched
source: >-
  https://developers.bluestack.app/adserving/ad-request-api-documentation,
  https://developers.bluestack.app/adserving/open-rtb-bid-request-api,
  https://developers.bluestack.app/reporting/seller-reporting-api,
  https://developers.bluestack.app/reporting/buyer-reporting-api,
  https://developers.bluestack.app/reporting/mediation-reporting-api,
  https://developers.bluestack.app/android/,
  https://github.com/azerion/improvedigital-publisher-mcp-server
note: >-
  No OpenAPI is published for any Madvertise-branded API, so this profile is captured
  from the developer docs rather than derived. Madvertise runs THREE distinct and
  unrelated identity models, which is the single most important thing for an agent to
  know about this provider: the ad-serving APIs are unauthenticated and identify
  inventory by placement code; the reporting APIs use a bearer-style opaque token minted
  by a dedicated /auth-reporting endpoint; and Azerion's sibling Improve Digital MCP
  server uses OAuth2 client credentials against a different host entirely.
summary:
  types: [placement-code, app-id, token, oauth2]
  api_key_in: [header]
  oauth2_flows: [clientCredentials]
schemes:
- name: placement-code
  type: identifier
  surface: ad-serving
  location: query-or-path
  detail: >-
    Ad requests carry the zone/publisher/placement ID in the `s` query parameter
    (mobile.mng-ads.com) or the URL path (/bidrequest/{placement_code}). This identifies
    inventory, not an authenticated principal — anyone who knows a placement code can
    issue a bid request against it. No key, token, signature or mTLS is documented.
  source: https://developers.bluestack.app/adserving/ad-request-api-documentation
- name: app-id
  type: identifier
  surface: mobile-sdk
  location: sdk-init
  detail: >-
    Mobile SDKs initialize with a publisher appID via MobileAds.sharedInstance() (iOS) /
    SDK init (Android) before loading ads.
  source: https://developers.bluestack.app/ios/
- name: reporting-token
  type: http
  scheme: token
  surface: reporting
  location: header
  parameter_name: Authorization
  token_endpoint: POST /auth-reporting
  detail: >-
    "Use the token returned by auth-reporting service when making calls to
    /seller-reporting, /buyer-reporting and /mediation-reporting." The token is an
    opaque 40-character hex string sent bare in the Authorization header — NOT prefixed
    with "Bearer", per the docs' own curl examples
    (`-H 'Authorization: fbe74e915898ee0d560643d0f3dd722eb17bade3'`). No expiry,
    refresh, rotation or revocation semantics are documented, and no scopes exist.
  gated: true
  gate_detail: >-
    The reporting host itself is withheld: "All API access is over HTTPS, and accessed
    via the https://xxx.com domain (ask to your Azerion contact)." The reference is
    public but the base URL is issued only to contracted partners.
  source: https://developers.bluestack.app/reporting/seller-reporting-api
- name: improvedigital-oauth2
  type: oauth2
  surface: sibling (Improve Digital 360Yield publisher inventory — NOT Madvertise ad serving)
  flows:
  - flow: clientCredentials
    tokenUrl: null
    scopes: {}
  detail: >-
    Azerion's Improve Digital publisher MCP server authenticates to api.360yield.com
    with OAuth2 client credentials (IMPROVE_DIGITAL_CLIENT_ID / _CLIENT_SECRET) and
    manages bearer-token expiry internally. Recorded for completeness because it is the
    only OAuth2 anywhere in this estate; it does not apply to the mng-ads.com APIs. No
    token URL or scope list is published, so no scopes/ artifact is emitted.
  source: https://github.com/azerion/improvedigital-publisher-mcp-server
gaps:
- No API key, token or signature on the OpenRTB bid-request endpoint — a placement code
  is the whole credential.
- No published scope model anywhere; the reporting token is all-or-nothing per account.
- No token lifetime, rotation or revocation documented for /auth-reporting.
- No /.well-known/oauth-authorization-server or openid-configuration on any host
  (see well-known/madvertise-well-known.yml).
cross_links:
  conventions: conventions/madvertise-conventions.yml
  mcp: mcp/madvertise-mcp.yml
  well_known: well-known/madvertise-well-known.yml