Quick answer
Every affiliate postback URL accepts the same core set of parameters: click_id (required, links the conversion to the original click), amount or sale_amount (the conversion value for commission calculation), txn_id or order_id (a unique transaction identifier for deduplication), and optional event, currency, coupon_code, and sub1-sub5 fields for richer attribution data. Different platforms use different parameter names but the underlying schema is largely consistent.
The core postback URL pattern
A standard affiliate postback URL looks like this:
`
GET https://track.platform.com/postback?click_id=`
The HTTP method is almost always GET (some platforms accept POST as well). The parameters live in the URL query string. The response is a small JSON object or plain text confirming the conversion was recorded. The whole request is typically 50-200ms end-to-end including network latency.
The parameter names vary by platform. The shape of the data is consistent: identifier, value, transaction ID, plus optional metadata.
Required parameters
click_id
The unique identifier from the original affiliate click. This is the bridge between the click and the conversion — without it, the tracking platform can't attribute the conversion to any affiliate.
The click ID is generated by the tracking platform at click time and embedded in the redirect URL as a parameter. Your backend reads it on landing, stores it server-side against the visitor's session or user record, and retrieves it when the conversion fires.
Common parameter names: click_id, clickid, cid, subid (older networks), tid (transaction-style platforms).
Format: typically a UUID (a7f9c3e2-4b1d-...) or a base32/base62 short identifier. Always treat as opaque — never parse or generate yourself.
Example value: a7f9c3e2-4b1d-49a2-9e7f-2d8b4c5e1f0a
amount or sale_amount
The conversion value used to calculate the affiliate's commission. For revenue-share offers, this is the gross sale amount. For CPA offers, it can be sent for reporting purposes even though the payout is fixed.
Common parameter names: amount, sale_amount, sum, value, revenue, payout.
Format: decimal number, sometimes integer cents. Match your platform's expected format.
Example value: 89.50 or 8950 (cents)
txn_id or order_id
A unique transaction identifier. The platform uses this to deduplicate conversions — if your backend accidentally fires the same postback twice (network retry, application bug), the platform recognizes the duplicate txn_id and counts the conversion once.
Common parameter names: txn_id, transaction_id, order_id, external_id.
Format: string. Typically your internal order ID or transaction reference. Should be unique across all conversions for a given affiliate program.
Example value: ORD-2026-04-30-789123
Optional parameters
event or goal
The type of conversion. Used when a single offer can produce multiple conversion event types (sale, lead, signup, renewal). The tracking platform applies different payout rules based on the event type.
Common parameter names: event, goal, event_name, conversion_type.
Common values: sale, lead, signup, trial_start, subscription_active, renewal, upgrade, qualified_lead.
When to send: required if your offer has multiple conversion event types with different payouts. Otherwise the platform defaults to "sale".
currency
Three-letter ISO 4217 currency code. Important for programs operating across multiple markets where the conversion amount could be in different currencies.
Common parameter names: currency, currency_code, cur.
Format: three uppercase letters.
Example values: USD, EUR, GBP, CAD.
When to send: any time the conversion amount is in a non-default currency, or always for clarity.
coupon_code
The promotional code the customer used at checkout. Used for coupon-based attribution where the affiliate is identified by which coupon was redeemed rather than by click ID.
Common parameter names: coupon, coupon_code, promo_code, code.
When to send: any time a coupon code was used, even alongside a click ID. Coupon attribution can override or supplement click-based attribution depending on platform configuration.
Sub IDs (sub1 through sub5)
Custom string fields that affiliates pass through their tracking links to segment their reporting. The affiliate appends these to their tracking URL, your platform stores them on the click, and they're included in the postback so the affiliate can see attribution for specific campaigns or sources.
Common parameter names: sub1, sub2, sub3, sub4, sub5, aff_sub, aff_sub2.
Use cases: campaign IDs, ad-set IDs, content piece identifiers, A/B test variants, source-specific tags.
Maximum length: typically 255 characters per field. Stick to URL-safe characters.
Platform-specific extensions
Different platforms accept additional parameters for their specific features:
- Custom data:
custom,meta,data— JSON-encoded or URL-encoded custom fields - Customer identifiers:
customer_id,email_hash— for cross-device matching or LTV tracking - Product data:
product_id,product_category,quantity— for product-level attribution - Status:
status,state— for marking conversions as pending vs approved at fire time
Always check your tracking platform's documentation for the full list of accepted parameters.
Deduplication patterns
The txn_id parameter is the foundation of deduplication. The pattern is: send the same txn_id for the same conversion every time, even if your code accidentally fires the postback twice. The tracking platform sees the duplicate and ignores it.
Practical deduplication scenarios:
Pixel + postback dual-fire. Many programs run both as redundancy. Configure your pixel to also send the same txn_id. The platform deduplicates so the conversion counts once.
Webhook retries. If your conversion-firing code is in a webhook handler, the upstream service might retry on failure. Your code should fire postbacks idempotently — same txn_id for the same logical event regardless of retries.
Application bug recovery. If a deploy accidentally fires duplicate postbacks for past conversions, the txn_id deduplication prevents double-credit. This is why reusing transaction IDs from your existing order/payment system is the right pattern — your existing IDs are already unique.
Example complete postback URL
A real-world postback URL combining the standard parameters:
`
https://track.example.com/postback?
click_id=a7f9c3e2-4b1d-49a2-9e7f-2d8b4c5e1f0a
&amount=89.50
&txn_id=ORD-2026-04-30-789123
&event=sale
¤cy=USD
&coupon_code=SAVE10
&sub1=spring-campaign
&sub2=instagram-story
`
URL-encoded as a single line:
`
https://track.example.com/postback?click_id=a7f9c3e2-4b1d-49a2-9e7f-2d8b4c5e1f0a&amount=89.50&txn_id=ORD-2026-04-30-789123&event=sale¤cy=USD&coupon_code=SAVE10&sub1=spring-campaign&sub2=instagram-story
`
Frequently asked questions
What's the difference between click_id and txn_id in a postback URL?
click_id identifies the original affiliate click — generated by the tracking platform at click time and stored in your database against the visitor. txn_id identifies the specific conversion transaction — generated by your application (typically your order ID) and used for deduplication. Both are required for reliable postback tracking: click_id for attribution, txn_id for deduplication.
Are postback URL parameters case-sensitive?
Parameter values typically are case-sensitive (especially click IDs). Parameter names are usually case-insensitive but case the parameter name to match the platform's documentation conventions. When in doubt, lowercase parameter names is the safest convention.
How do I send custom data in a postback URL?
Use sub IDs (sub1 through sub5) for custom string fields the affiliate passes through their tracking link. Use platform-specific custom-data parameters (custom, meta) for arbitrary JSON-encoded data. For larger payloads, switch from GET to POST with a JSON body — most platforms support both.
What if my conversion has no click_id (direct traffic)?
If a conversion happens without an associated affiliate click, you typically don't fire a postback at all — there's no affiliate to attribute the commission to. Some programs use coupon-only attribution where the coupon_code parameter substitutes for click_id. In that case, send the postback with coupon_code set and let the platform's coupon-attribution logic identify the affiliate.
Can I send the same postback to multiple platforms?
Yes — fire one HTTP request per platform from your conversion handler. Each platform has its own postback URL and parameter conventions; you'll need a small adapter per platform that maps your internal conversion data to that platform's expected schema. Many tracking layers (server-side GTM, Segment, custom services) handle this fan-out for you.
What's the recommended approach for postback security?
Add a secret token parameter (secret, token, auth) that the tracking platform validates. Use HTTPS for all postback URLs. Optionally restrict postback acceptance by source IP if your tracking platform supports IP allowlisting. Don't put authentication tokens in the URL if logs are widely accessible — POST bodies or headers are safer for sensitive auth.
Are there any required parameters that platforms don't always document?
click_id is universally required. txn_id is technically optional on some platforms but recommended everywhere for deduplication. amount is required for revenue-share offers but optional for CPA offers (though sending it is still useful for reporting). Beyond these three, almost everything is optional and platform-specific.
Trcker tip
Trcker's postback endpoint accepts the standard parameters with sensible defaults: click_id (required, UUID format), amount in dollars or cents (auto-detected by magnitude), txn_id (recommended, used for deduplication), plus optional event, currency, coupon_code, and sub1-sub5. Each offer can override the parameter names if you're integrating with an existing system that uses different conventions — for example, mapping your internal order_id field to Trcker's txn_id. See setting up postbacks for the configuration guide.