What Is a Postback? Webhooks vs Postbacks vs Server-to-Server Tracking

Your app records a purchase, the ad platform never sees it, and campaign optimization starts learning from incomplete data. A reliable postback closes that gap—but only if the event reaches the right system, carries the right identifier, and can survive retries without creating duplicate conversions.

The terminology makes the implementation harder than it needs to be. Teams often use *postback*, *webhook*, and *server-to-server tracking* as if they were exact synonyms. They all use backend HTTP requests, but they describe different parts of a measurement system. This guide defines each term, traces a mobile conversion from click to callback, and gives you a production checklist for choosing and operating the right flow.

What is a postback?

A postback is a server-originated callback that reports an event—usually a conversion—to another platform. In mobile marketing, a mobile measurement partner (MMP) or advertiser typically sends a postback to an ad network so the network can credit an install or in-app event and use that signal for reporting or campaign optimization.

The word describes the callback's role, not one mandatory HTTP format. A platform may implement a postback as an HTTPS request with values in a query string, a form-encoded body, or JSON. It may even accept GET as well as POST; for example, Adjust's S2S event endpoint accepts GET and multiple POST formats. Follow the receiver's contract rather than assuming the name guarantees a method or payload type.

Why “postback” can mean two different things

Searches for “postback form” often mix two concepts:

• In classic web frameworks such as ASP.NET, a form postback submits page data back to the same page or server route for processing.
• In advertising and attribution, a postback is a callback between systems that reports a click, install, purchase, approval, or other event.

Both involve sending data back, but only the second meaning is relevant to conversion tracking. When a vendor asks for a “postback URL,” it usually wants an HTTPS endpoint or URL template that its server will call after a qualifying event.

How a postback works in mobile attribution

A postback does not discover attribution by itself. It carries the result of an attribution or conversion decision from one system to another. The durable link is usually an identifier captured earlier in the journey.

Here is the common flow:

1. The user taps an ad or referral link. The ad network supplies a click ID or another campaign identifier.
2. The tracking layer records the click. A deep linking or measurement platform stores the identifier with campaign context and routes the user onward.
3. The user installs or opens the app. The measurement system tries to connect the app activity to the earlier interaction using supported attribution signals.
4. A conversion occurs. That may be an install, registration, subscription, purchase, level completion, or backend-confirmed renewal.
5. The source of truth records the event. An SDK may capture an in-app action, while your backend should report events that only it can confirm, such as a settled payment or refund.
6. The measurement platform applies attribution rules. It decides which campaign, network, or partner receives credit.
7. A server fires the postback. The receiving platform gets the event name, attribution key, value, timestamp, and other permitted fields, then acknowledges the request.

Microsoft's server-side conversion documentation shows this pattern in practice: an auction token is captured at the click, retained by an attribution server, and returned when the app install is attributed so the conversion can be connected to the auction. Microsoft also describes mobile app sandboxing and the lack of browser cookies as reasons to use server-side conversion calls.

What a postback URL looks like

A templated postback might look like this before a platform substitutes real values:

https://network.example/conversion
  ?click_id={click_id}
  &event={event_name}
  &event_id={event_id}
  &value={revenue}
  &currency={currency}
  &timestamp={event_time}

The braces represent macros, not literal values. When the event fires, the sender replaces each supported macro with data from the attributed event. AppsFlyer's postback documentation explains that macros are replaced with event-specific data and that the available data can come from attribution links, SDK input, partner IDs, or the measurement platform.

The exact fields depend on the receiver, but a robust contract usually covers:

Do not send every available field by default. Treat the payload as a data-sharing contract: include what the receiving platform needs, document the purpose, and avoid unnecessary personal or device-level data.

Postback vs webhook vs server-to-server tracking

The cleanest way to separate the terms is by scope and purpose:

These are conventions, not protocol laws. A postback is technically a specialized callback and can be implemented like a webhook. A webhook is inherently server-to-server. “S2S” is the broadest term: it says where the request originates and terminates, not why it exists.

Postback: close a measurement or optimization loop

Use postback when you mean a conversion-oriented callback tied to attribution. In a mobile stack, the measurement platform often sends a mapped install or in-app event to the partner that drove the user. AppsFlyer supports postbacks for installs, in-app events, and blocked events, illustrating how postbacks can support both optimization and fraud-related feedback.

The receiver's schema controls the event name, allowed values, authentication, and response behavior. “Purchase” in your app may need to map to a partner-specific event token. If the names or conditions differ, the sender can record the event correctly while the partner receives nothing; AppsFlyer's troubleshooting guide calls out event mapping and configuration windows as common causes.

Webhook: react to a wider set of events

Use webhook when another service should notify a system you control. The event might be an attributed install, but it could just as easily be a subscription cancellation, data export completion, or configuration change. Webhooks generally carry a richer event envelope and are designed for extensible integrations rather than one advertising conversion contract.

The receiving endpoint must still be treated as a public production interface. GitHub recommends validating webhook deliveries with an HMAC signature, using HTTPS, and processing deliveries asynchronously so the endpoint can acknowledge them promptly.

S2S tracking: report events from a trusted backend

Use server-to-server tracking when the event source of truth is your backend or when a client SDK cannot reliably observe the event. A renewal charged by a billing system, a refund, or an order approved after fraud checks belongs on this path.

For example, Adjust documents an S2S API for sending in-app events from a server and recommends using its SDK for installs, sessions, and reattributions while reserving S2S for custom events. This highlights an important design point: S2S is not automatically a replacement for every SDK function. It is one input route into a complete measurement system.

Which postback or server-to-server pattern should you use?

Start with the event's source of truth and intended consumer:

• Your backend confirmed the event, and the MMP needs it: send an S2S event into the MMP.
• The MMP attributed the event, and the ad network needs an optimization signal: configure a partner postback.
• Your own systems need the attributed event: receive a webhook or raw-data callback from the MMP.
• The browser owns the only observable conversion and you need quick setup: a pixel may be practical, but understand its browser and page-load dependencies.
• Apple generates the privacy-preserving attribution result: receive and verify the Apple postback rather than treating it like a normal deterministic user-level callback. See the SKAdNetwork explainer for the surrounding privacy model.

Most mature app stacks use more than one pattern. A backend purchase may enter the MMP over S2S, leave as a partner postback for campaign optimization, and also leave as a webhook to the company's warehouse. The goal is not to choose one fashionable transport; it is to give each event one authoritative source and each consumer one deliberate delivery path.

Deeplinkly brings deep links, deferred deep links, attribution, REST APIs, webhooks, and raw data export into the same developer-first measurement workflow. That can reduce the number of disconnected handoffs while still letting app teams send backend-confirmed events and route attributed outcomes to the systems that need them.

How to implement postback tracking that survives production

The happy path is a single request followed by 200 OK. Production systems must also handle duplicate delivery, timeouts, malformed values, delayed events, replay attempts, and partial outages.

1. Define the event contract before the URL

For each event, write down:

• the business definition and source of truth;
• when it becomes final enough to send;
• the unique event ID and attribution key;
• whether value, currency, and refunds are supported;
• which partner is allowed to receive it;
• the expected request method, content type, authentication, and response codes;
• the retry and expiry policy.

This prevents a technical integration from masking a business disagreement. “Purchase” might mean checkout started, payment authorized, payment settled, or order kept beyond a return window. No callback can reconcile systems that use different definitions.

2. Preserve identifiers through the journey

Capture the click or partner identifier at entry, validate it, and persist it with the user's or transaction's server-side record when your privacy basis allows. Do not depend on reconstructing it at conversion time.

Keep acquisition IDs separate from your own immutable event IDs. The acquisition ID answers “which interaction may receive credit?” The event ID answers “have I processed this exact conversion before?” You need both for accurate matching and safe retries.

3. Authenticate the sender and minimize payloads

Use HTTPS and the receiver's strongest supported authentication scheme. For webhook-style bodies, sign the raw request bytes and verify the signature before parsing or acting on the event. Compare signatures with a constant-time function; GitHub's validation guidance explicitly recommends constant-time comparison.

Protect against replay with a timestamp tolerance and a unique delivery or event ID. Rotate secrets deliberately, support an overlap window during rotation, and redact tokens and personal data from logs.

Apple's privacy-preserving postbacks require their own verification flow. Apple instructs receivers to verify the postback signature and count only unique postback identifiers. Do not count a payload merely because it reached the correct endpoint.

4. Make processing idempotent

Assume a valid request can arrive more than once. The receiver should store a unique event or delivery key and make the second processing attempt a no-op while still returning a successful acknowledgement.

This is essential because delivery retries are normal. AppsFlyer, for example, can retry certain failed partner postbacks, and its documentation warns that a delayed response after successful processing can produce duplicates. AppsFlyer tells partners to implement deduplication.

HTTP does not make POST idempotent for you. RFC 9110 defines POST as non-idempotent by default, so the application must supply idempotent behavior through stable keys and transaction logic.

5. Acknowledge quickly, then process asynchronously

At the edge of your system:

1. authenticate the request;
2. validate the minimum schema;
3. durably enqueue or persist the delivery;
4. return the documented success response;
5. perform slower enrichment and downstream work asynchronously.

Do not hold the connection open while updating five downstream systems. A slow response can be interpreted as failure even after your database write succeeds, triggering a retry. GitHub's webhook guidance recommends returning a 2XX response within 30 seconds and using a queue for asynchronous processing.

6. Retry selectively and expose failures

Retry timeouts, connection failures, 429 responses, and retryable 5xx errors with exponential backoff and jitter. Do not endlessly retry permanent contract errors such as bad authentication, an unknown event name, or invalid parameters.

Set a maximum attempt count or delivery age, then move exhausted deliveries to a dead-letter queue. Provide a safe replay mechanism that keeps the original event ID. A replay tool that invents a new ID defeats deduplication and can inflate revenue.

7. Reconcile, do not just monitor uptime

Endpoint uptime tells you whether requests can arrive. It does not tell you whether the right events arrived with the right values.

Track at least:

• sent, acknowledged, retried, rejected, and exhausted deliveries;
• latency from event time to receipt time;
• missing or invalid attribution IDs;
• duplicate rate;
• event counts and revenue by source, event name, app, and day;
• discrepancies between backend, MMP, and partner totals.

Alert on changes in ratios, not only absolute failures. A mapping mistake may still return 200 OK while quietly dropping revenue from partner reports.

A pre-launch postback testing checklist

Run the integration through a controlled journey before spending against it:

1. Generate a real test click and record the resulting identifier.
2. Complete the intended conversion using a test account or sandbox.
3. Confirm the source system stored the correct event name, time, value, and currency.
4. Inspect the outbound request with secrets and personal data redacted.
5. Confirm the receiver matched the expected click and campaign.
6. Send the same event ID again and verify the count does not increase.
7. Force a retryable error, then confirm backoff and eventual delivery.
8. Send an invalid signature or token and confirm rejection.
9. Test a late event, missing optional field, and wrong event name.
10. Reconcile all three totals: backend event, measurement event, and partner event.

Keep the test evidence. When reporting diverges later, a known-good request, response, and mapping gives you a baseline for finding what changed.

Common postback mistakes

Treating a successful response as successful attribution

A 200 response proves that an endpoint accepted the request according to its contract. It does not prove that the receiver attributed the event to the campaign you expected. Verify the event in the destination's logs or reporting surface.

Sending client-observed revenue as final revenue

The app may know that a button was tapped, but the backend knows whether payment settled, was refunded, or was rejected. Send revenue from the authoritative system and define how later adjustments are represented.

Mapping names without version control

Event names, partner tokens, and payload fields evolve. Store mapping changes with an owner, effective date, and rollback path. A case-only change can be enough to stop delivery on systems where parameters are case-sensitive.

Logging complete postback URLs

Query strings can contain access tokens, advertising identifiers, transaction IDs, or revenue details. Redact sensitive fields at ingestion and avoid placing long-lived secrets in URLs when headers or signed bodies are supported.

Assuming server-side means privacy-safe

Moving data off the browser changes transport reliability; it does not remove privacy obligations. Minimize the payload, respect consent and platform rules, set retention limits, and document each recipient and purpose.

Frequently asked questions

What is a postback URL in simple terms?

A postback URL is an endpoint or URL template that one server calls to report an event to another system. In advertising, it usually sends a conversion and an identifier that lets the receiver connect that conversion to an earlier click or campaign.

Is a postback the same as a webhook?

Not exactly. A postback is usually a conversion or attribution callback, while a webhook is a broader event-notification pattern. A postback can be implemented using the same HTTP techniques as a webhook.

Is a postback the same as server-to-server tracking?

A postback is one kind of server-to-server communication. S2S tracking is the broader architecture and can also describe your backend sending an event into an MMP, which is the opposite direction from many partner postbacks.

Does a postback have to use HTTP POST?

No. The name does not guarantee the HTTP method. Some systems use GET with query parameters; others accept POST with form or JSON bodies. Implement the exact method, encoding, and response behavior documented by the receiving platform.

Do postbacks work without cookies?

The delivery itself does not require the user's browser or a browser cookie because it occurs between servers. The overall attribution flow still needs a permitted identifier or matching method captured earlier in the journey.

What is a postback form?

In web development, a form postback submits form data back to the page or server for processing. In advertising tools, a “postback form” may instead mean the settings screen where you enter a conversion callback URL. Check the surrounding product language to see which meaning applies.

How do you prevent duplicate postback conversions?

Give every logical conversion a stable unique event ID, store processed IDs, and make repeated processing a no-op. Keep the same ID across retries and manual replays.

Conclusion: choose by direction, consumer, and source of truth

Use a postback to return a conversion or attribution result to a partner, a webhook to deliver a broader event into systems you control, and an S2S event when your backend needs to report an authoritative action into a measurement platform. In a complete mobile attribution stack, all three can work together.

Before launch, make the event contract explicit, preserve the matching identifiers, authenticate every request, deduplicate every retry, and reconcile destination totals against your backend. If you are evaluating an MMP, ask to see its postback mappings, retry behavior, webhook access, raw-data export, and S2S documentation—not just a dashboard demo.