The postback specification lists registration, FTD and approved action plus event ID, player ID, campaign ID, amount, currency, status, timestamp and signature.
What is calculated
Events and the exact moment they are emitted
Parameter names and permitted values
Signature method or shared secret
Retry and deduplication policy
Scenario
Postback availability and format must be confirmed for the account; prepare events, parameters, security controls and a test sequence.
Reconciliation
- Approve a sample request for each event
- Test the URL against a controlled endpoint
- Return 2xx only after durable storage
- Deduplicate retries by event ID
Risks
- Treat every deposit as FTD
- Accept unsigned requests
- Create duplicate conversions on retry
What belongs in the technical brief
Events, fields, signing, retries, event ID and response codes are documented before development. Acceptance includes redelivery of one event to prove deduplication. Without a raw log, it is impossible to locate whether failure occurred at the sender, network or endpoint.
Integration acceptance
A 200 response alone does not prove correct processing. The endpoint must retain event ID, associate it with click ID and accept a retry without creating a second conversion. Logs should keep time, signature result, request body and response code without exposing secret keys.
Test an unknown event and a request with an invalid signature as well. Both should fail predictably so accidental or forged requests cannot enter reporting.
What makes a postback useful for investigation
Every event needs a stable event ID and a clear relationship to click or SUB_ID. The receiver should store timestamp, event type, amount, currency and status without writing the signing secret into open logs. A retry of the same event ID must confirm or update the record without creating a second conversion.
Add negative tests for an invalid signature and an unknown event type. A predictable rejection is as important as a successful 200 because it proves that arbitrary requests cannot silently enter reporting.
The integration is ready when one event is traceable in sender and receiver logs by the same ID. Failures have explicit statuses and retries do not increase totals.
Frequently asked questions
What fields must a postback request include?
Event ID, player ID, campaign ID, amount, currency, status, timestamp and a signature — without them it's hard to tie an event to a specific click or guard against spoofing.
How do you confirm a postback isn't creating duplicate conversions?
Resend the same event and confirm it gets deduplicated by event ID instead of counting as a second conversion.
What should the endpoint return for acceptance testing to pass?
A 200 response only after the event is actually saved, not immediately on receipt — otherwise a network error can look like a successful processing.