Skip to main content

​
Worked chains — pixels and redirects on your campaign

The root-mounted families below don’t share a request envelope: each answers with its own content type, driven by what the caller’s Accept header asks for. If the concept page’s public pixels, redirects, and short links is the contract, the three chains below are the wire.

​
1. Embed an open pixel and a referral redirect in one campaign template

In your email (or landing) template:
The pixel answers with the transparent GIF and a body of no claim:
A recipient following the link gets the redirect:
When the code is unknown, what comes back depends on the caller’s Accept:

​
2. Programmatic landing-page converts with Idempotency-Key

POST /lp/:code/convert is the family’s one JSON-capable route. Send Accept: application/json plus a stable key:
Replay the same key plus credential and the cached response returns unchanged — the original envelope replays within the 24h retention with Idempotency-Replay: true on the response header:
The rendered opt-in form itself omits the header — the anonymous browser submit records once per submit; only a programmatic client sees the replay semantics.

​
3. Verify the HMAC on /r/:sig/:target

/:target is base64url JSON over the exact wire bytes; /:sig is the base64url HMAC-SHA256 of those bytes. A tampered (re-encoded) segment is rejected before any redirect. Valid:
Re-serialized (different key order, pretty-printed, normalized ts):
The signature gate decides whether the engagement is recorded; it never changes what the recipient renders. Pixels render on every path, and the redirect accepts no malformed wire form.
For the full signing model (which tuple each family signs) and the interaction with the delivery lifecycle, see public pixels, redirects, and short links and email delivery lifecycle.