Truex Media Authentication

generated: '2026-08-12'
method: searched
source: >-
  Derived from the provider's own published reference in
  https://github.com/socialvibe/truex-ads-docs (web_service_ad_api.md,
  reporting_api.md, js_ad_api.md) plus live unauthenticated probes of
  get.truex.com, api.truex.com and mcp.infillion.com. true[X] publishes no
  OpenAPI, so there are no securitySchemes to derive from; every scheme below
  is read from the provider's documentation and confirmed against a live
  response where possible.
docs: https://github.com/socialvibe/truex-ads-docs/blob/master/web_service_ad_api.md
summary:
  types:
  - apiKey
  - oauth2
  - hmac
  api_key_in:
  - query
  oauth2_flows:
  - authorizationCode
  spec_derived: false
  note: >-
    Three distinct auth models across four surfaces. The ad-request surface is
    identified by an opaque placement key rather than a secret; the reporting
    surface uses a query-string API key; the server-to-server callback is
    HMAC-SHA1 signed with a shared application_secret and IP-allowlisted; the
    parent-company MCP gateway is OAuth 2.1.
schemes:
- name: reporting_api_key
  api: truex-media-reporting-api
  type: apiKey
  in: query
  parameter: api_key
  required: true
  issued_by: true[X] (partner-specific reporting API key, provisioned manually)
  description: >-
    The partner-specific reporting API key provided by true[X]. Passed as a
    query-string parameter on every Reporting API request.
  transport_note: >-
    The published reference documents the endpoint over plain http://. The host
    301s http to https, but the key is carried in the URL query string either
    way, so it is exposed to logs, proxies and Referer headers. Recommend a
    header-based credential.
  verified:
    url: https://api.truex.com/v1/publisher/performance.json?api_key=<invalid>&start_date=2026-01-01
    http_status: 401
    body: '401 Unauthorized: Invalid API key'
    fetched: '2026-08-12'
  source: https://github.com/socialvibe/truex-ads-docs/blob/master/reporting_api.md
- name: placement_key
  api: truex-media-web-service-ad-api
  type: apiKey
  in: query
  parameter: placement.key
  aliases:
  - placement_hash
  - partner_config_hash
  required: true
  issued_by: true[X] (one placement key per integrating publisher placement)
  description: >-
    A unique alphanumeric identifier generated by true[X] that identifies the
    publisher placement making the ad request. Documented as an identifier, not
    a secret — it is embedded in client-side integrations and in VAST tags.
  transport_note: >-
    Not a confidential credential. The Web Service Ad API additionally requires
    user.id, ip and user_agent on server-side calls; access control is by
    placement provisioning and bid eligibility rather than by a secret.
  verified:
    url: https://get.truex.com/v2
    http_status: 400
    body: '{"error":"partner_config_hash is missing","request_id":"..."}'
    fetched: '2026-08-12'
  source: https://github.com/socialvibe/truex-ads-docs/blob/master/web_service_ad_api.md
- name: engagement_callback_signature
  api: truex-media-web-service-ad-api
  surface: server-to-server callback (true[X] -> partner)
  type: hmac
  algorithm: HMAC-SHA1
  encoding: base64, then URL-escaped
  parameter: sig
  key: application_secret (partner-specific, issued by true[X])
  identity_parameter: application_key
  canonicalization: >-
    Parameters as key=value pairs, sorted alphabetically by key, concatenated
    with no separator, with the application_secret appended to the string before
    the HMAC is computed.
  description: >-
    Every engagement callback true[X] sends to a partner's callback URL is
    signed, so the partner can verify the request originated from true[X] and
    was not forged.
  additional_controls:
  - engagement_id uniqueness validation (duplicate suppression)
  - source IP allowlist (8 published egress addresses)
  source: https://github.com/socialvibe/truex-ads-docs/blob/master/web_service_ad_api.md
- name: infillion_agent_connector_oauth
  api: infillion-agent-connector-mcp
  surface: https://mcp.infillion.com/mcp
  type: oauth2
  operator: Infillion (parent company)
  flows:
  - flow: authorizationCode
    authorizationUrl: https://mcp.infillion.com/oauth/authorize
    tokenUrl: https://mcp.infillion.com/oauth/token
    registrationUrl: https://mcp.infillion.com/register
    pkce: S256
    refresh: true
    scopes: {}
    scopes_note: >-
      The RFC 8414 metadata publishes no scopes_supported and Infillion
      publishes no scope reference, so no scopes are recorded. A scopes/
      artifact is deliberately NOT emitted rather than invented.
  token_endpoint_auth_methods_supported:
  - none
  discovery:
  - well-known/truex-media-oauth-authorization-server.json
  - well-known/truex-media-oauth-protected-resource.json
  verified:
    url: https://mcp.infillion.com/mcp
    http_status: 401
    www_authenticate: 'Bearer realm="Infillion Gateway"'
    fetched: '2026-08-12'
  source: https://mcp.infillion.com/.well-known/oauth-authorization-server
gaps:
- No published OAuth or OIDC on the true[X] APIs themselves.
- No documented key rotation, expiry or revocation procedure for the reporting API key.
- No documented scopes or permission model on any surface.
- Reporting credential travels in the query string rather than an Authorization header.
- No OpenAPI, so none of this is machine-readable from the provider.