generated: '2026-08-06'
method: searched
source: >-
  openapi/applike-justtrack-management-openapi.yml, openapi/applike-justtrack-app-events-openapi.yml,
  https://docs.justtrack.io/api/reporting-api/acquisition/,
  https://docs.justtrack.io/api/revenue-events-api/api-for-customers/,
  https://docs.adjoe.io/rewarded-solutions/reporting-apis/revenue-api,
  https://docs.adjoe.io/rewarded-solutions/setting-up-rewarding/server-to-server-payouts
summary: >-
  Two independent API estates under one group, with different conventions. justtrack is a Go-generated (oapi-codegen)
  JSON API that uses POST for reads, an offset/limit page object inside the request body, and a flat {"error": "..."}
  envelope. adjoe's SSP APIs are conventional GET + query-string REST with documented rate-limit headers. Neither
  publishes RFC 9457 problem+json. Idempotency exists on the ingest paths — but as client-supplied unique identifiers
  in the payload, not as an Idempotency-Key header.

auth:
  style: api-key
  detail: X-API-Key header (justtrack), X-API-KEY header (adjoe), apikey query parameter (justtrack revenue sink)
  see: authentication/applike-authentication.yml

idempotency:
  supported: true
  style: client-supplied-dedup-key
  mechanism: payload identifier, not a header
  header: null
  keys:
  - api: justtrack AppEvent API
    field: batchId
    location: request body, per AppEventBatch
    format: uuid4 (exactly 36 characters)
    semantics: >-
      "A batch of AppEvents, all for one app user combination. If one event is invalid, the whole batch is rejected."
      Failures are reported per batchId in the 207 response, so the caller can retry exactly the batches that failed.
    evidence: openapi/applike-justtrack-app-events-openapi.yml components.schemas.AppEventBatch
  - api: justtrack AppEvent API
    field: id
    location: request body, per AppEvent
    format: uuid4
    semantics: '"Globally unique id of the event." — the per-event dedup key.'
    evidence: openapi/applike-justtrack-app-events-openapi.yml components.schemas.AppEvent
  - api: justtrack Revenue Events API
    field: transactionid
    location: query parameter
    semantics: '"Unique transaction ID that can be used to trace and deduplicate events" (verbatim from the docs).'
    evidence: https://docs.justtrack.io/api/revenue-events-api/api-for-customers/
  - api: adjoe server-to-server rewarded payout callback
    field: trans_uuid
    location: query parameter on the callback adjoe sends to the publisher
    semantics: >-
      "The unique transaction ID." adjoe retries a failed callback after 10 minutes, again after another 10 minutes,
      then every 2 hours for roughly 12 hours — so the receiving publisher MUST deduplicate on trans_uuid or it will
      double-credit users.
    evidence: https://docs.adjoe.io/rewarded-solutions/setting-up-rewarding/server-to-server-payouts
  retention: not documented
  gap: >-
    No Idempotency-Key request header is offered on the mutating Management API operations (create app, create
    campaign, connect partner, upload bids). Retrying a create there is not safe.

pagination:
  justtrack_management:
    style: offset-limit
    location: request body (the APIs use POST for list operations)
    object: page
    params:
      offset: integer, minimum 0 — "The number of resources to skip for this filter"
      limit: integer, 0..1000 — "The maximum number of resources in a page. If set to 0, we default to a limit of 100."
    default_limit: 100
    max_limit: 1000
    response_fields: not documented as a cursor/next-link; callers advance offset themselves
    evidence: openapi/applike-justtrack-management-openapi.yml components.schemas.RequiredPage
  justtrack_reporting:
    style: page-limit
    location: request body
    object: pagination
    params:
      page: integer
      limit: integer
    ordering: orderBy {name, direction}
    evidence: https://docs.justtrack.io/api/reporting-api/acquisition/
  adjoe_ssp:
    style: none
    detail: date-range bounded queries (start_at / stop_at); no pagination documented

filtering_and_shaping:
  justtrack_management:
    style: typed filter object per list operation (ListAppsFilter, ListBidsFilter, ListCampaignsFilter, ListPartnersFilter, ...)
  justtrack_reporting:
    style: >-
      metrics[] + dimensions[] + filters{dimension: [values]} + cohort{enabled, dx[]} + interval{from, until};
      up to 3 dimensions per request
  adjoe_ssp:
    style: group_by query parameter, comma-separated; defaults to date,sdk_hash,platform; 18 dimensions available
  field_expansion: not supported on any surface
  sparse_fieldsets: not supported on any surface

metadata:
  supported: partial
  detail: >-
    justtrack AppEvent carries a free-form `dimensions` object per event for caller-defined attributes. There is no
    general-purpose metadata field on the Management API resources.

request_tracing:
  request_id_header: not documented on any surface
  correlation: >-
    Correlation is done through domain identifiers instead — batchId / event id (AppEvent), transactionid (revenue),
    trans_uuid (adjoe payouts).

versioning:
  style: path-segment
  detail: >-
    Version lives in the URL path per surface, and the surfaces are not versioned in lockstep:
    /management/v1, /reporting/v2 (with v1 still documented), /appevents/v1, /monetization/v0,
    /v2/ssp-api (adjoe revenue), /v3/ssp-api (adjoe user ad data report).
  spec_version_field: info.version "v1.0.0" on both published OpenAPI documents
  see: lifecycle/applike-lifecycle.yml

errors:
  format: proprietary-json
  rfc9457: false
  envelopes:
  - api: justtrack Management API and AppEvent API
    shape: '{"error": "<description of the error>"}'
    schema: ErrorResponse -> Error (string, minLength 1)
  - api: justtrack AppEvent API (partial success)
    status: 207
    shape: '[{"batchId": "...", "statusCode": 400, "error": "validation failed"}]'
    schema: MultiErrorResponse -> BatchErrorResponse
    note: >-
      A genuinely good bulk pattern — per-item status and error keyed by the caller's own batchId, so retries are
      surgical.
  - api: adjoe User Ad Data Report API
    status: 202
    shape: '{"error": "report is pending generation"}'
    note: adjoe reuses the `error` key for a non-error, still-generating state.
  content_type: application/json
  see: errors/applike-problem-types.yml

rate_limits:
  documented: partial
  adjoe_ssp:
    sustained: 5 requests per second per publisher
    burst: 10 requests per publisher
    headers:
      X-RateLimit-Limit: burst size
      X-RateLimit-Remaining: requests available
      X-RateLimit-Reset: seconds until replenishment
      Retry-After: sent on 429 responses only
    status_code: 429
  justtrack:
    documented: false
    detail: >-
      No rate limits, quotas or throttling headers are published for any justtrack API, and neither OpenAPI document
      declares a 429 response.
  see: rate-limits/applike-rate-limits.yml

retries:
  adjoe_s2s_callback:
    schedule: 10 minutes, then 10 minutes, then every 2 hours for approximately 12 hours total
    success_signal: HTTP 200 from the publisher endpoint; anything else is treated as a failure
    evidence: https://docs.adjoe.io/rewarded-solutions/setting-up-rewarding/server-to-server-payouts
  justtrack_app_events:
    guidance: >-
      502 responses are documented as "Bad Gateway while committing the events, please try again after a short
      backoff." No backoff schedule or jitter guidance is given.

http_semantics:
  read_via_post: >-
    justtrack uses POST for list/read operations (POST /management/v1/apps, POST /management/v1/campaigns,
    POST /reporting/v2/acquisition/table). Reads are therefore not cacheable, not bookmarkable and not safely
    retryable by intermediaries. This is a deliberate design choice driven by large typed filter bodies, but it is
    the single biggest deviation from REST convention on this provider's surface.
  conditional_requests: not supported
  caching_headers: not documented