Postback / Developer API Terms

“Postback” means a server-to-server HTTP request sent by an operator (or by an authorised third-party tracking platform acting on the operator’s behalf) into a BetLink-issued endpoint to report an affiliate-attributable conversion event. “Developer API” means any HTTP endpoint published under “https://app.betlink.ai/api/” intended for programmatic access by partners or self-serve affiliates.

By sending postbacks or calling the developer API you accept these terms in addition to your underlying agreement with BetLink (Operator Term Sheet or Affiliate Terms of Service).

Postbacks must be sent only to BetLink-issued URLs. The current stable endpoint family is /api/postbacks/{provider}. Each operator receives a tenant-scoped URL with a stable shared secret on partnership go-live; do not share that URL or its secret with other operators or third parties.

Every postback must include the agreed shared-secret HMAC signature in the x-betlink-signature header, computed as HMAC-SHA256 of the raw request body using the tenant secret. Requests with missing, malformed, or stale signatures (skew > five minutes) are rejected with HTTP 401 and not retried.

The canonical postback payload is JSON; URL-encoded form-bodies are accepted for legacy tracker compatibility. The required fields are click_id (the BetLink-issued sub-id), event_type (one of registration, ftd, ngr_share, rejected, refund), payout_amount (decimal, four-place precision), and payout_currency (ISO 4217). Optional fields and the supported macro substitutions for tracker integrations (Voluum, BeMob, RedTrack, Binom, Keitaro) are documented in the BetLink Postback Integration Guide shipped with your shared secret.

Each postback must include an operator_conversion_id that is stable for the lifetime of the conversion. BetLink dedups on the tuple (tenant, operator_conversion_id, event_type); re-sends with the same tuple are accepted as no-ops and return HTTP 200. Duplicate FTD events with different ids are treated as potentially fraudulent and flagged for manual review.

Endpoints accept up to one hundred (100) requests per second per tenant; bursts above that are throttled with HTTP 429 and Retry-After set. Operators (or their tracker) should retry with exponential backoff at 30s, 5m, 30m, 2h, and 12h. After the 12h retry, the request is considered abandoned; surface the failure in your tracker for manual escalation.

Operators are responsible for the accuracy of the conversion data they send. Submitting payout amounts that materially diverge from your internal ledger, or repeatedly correcting events with refund/rejected after payout has been credited to the affiliate, may trigger automatic reconciliation holds and partnership review.

All postbacks must be sent over TLS 1.2 or higher. Plaintext HTTP is rejected. We accept any valid certificate chain trusted by the standard public-CA bundle; pinning to a specific certificate is not required and may break with our normal cert rotation.

Shared secrets may be rotated on demand by either party. Rotation is performed by setting a _PREV slot for ninety (90) days of overlap before the old secret is retired. Both signatures are accepted during the overlap window. We will signal scheduled rotations at least seven (7) days in advance; ad-hoc security rotations may use a shorter window with notification.

BetLink targets 99.9% monthly availability for the postback receivers. Status page and incident history are at the BetLink status surface (link shipped at integration time). We will not back-fill conversions that fall outside the documented retry window because of an operator tracker outage; we will back-fill if a confirmed BetLink-side outage is the cause.

We may suspend a tenant’s postback intake without notice for confirmed signature compromise, repeated payload-injection attempts, or partnership-level termination per the Operator Term Sheet. Routine partnership wind-down provides for a thirty (30) day intake window for trailing conversions tied to clicks already in flight, after which the endpoint returns HTTP 410.

Operational integration questions and incident reports go to the BetLink integrations team. Access requests for the developer API, schema-change notice, or escalation of a rotation issue: see the contact details on /imprint.