Handling retries
Retries happen on Toplu's side, per destination, automatically. There's nothing to implement on yours beyond sending a stable id.
What gets retried
A destination's response is classified retryable or not. A timeout or a 5xx is retryable, the destination is temporarily down, trying again later can succeed. A 4xx, an invalid field or a rejected hash, is not, sending the identical payload again will just fail the same way. Toplu retries the first kind on its own and reports the second kind straight back to you in the delivery-status response, no point queueing a request that can't succeed.
Backoff, and why it has jitter
Each retry waits longer than the last, capped at a maximum delay rather than growing forever, so a destination that's down for a while doesn't get retried in an increasingly useless pattern. A small random jitter is added to that wait, without it, every customer's retries for the same outage would land back on the destination at the same moment, the exact thundering-herd problem that made the outage worse in the first place, not better.
Resending is safe: use the same id
If your own system retries a request, for example because your server didn't get Toplu's response before timing out, send the exact same id again rather than generating a new one. A destination that already has an event with that ID recognizes it as the same conversion and won't double-count it, the same deduplication window most destinations already use to reconcile a browser-side pixel against a server-side event for the same purchase. Generating a fresh ID on every retry defeats this, and is the single most common cause of a conversion getting counted twice.
Need a hand?
Coding is hard sometimes, and that's okay. Visit our help center or reach out directly, we're here to help.