Postback Event API Setup Guide

Track events with Addressable's server-to-server postback

Addressable’s Events API is a modern server-to-server postback: your backend reports key funnel events (page_views, signups, wallet connects, purchases, etc.) so they can be attributed to campaigns and used for optimization.

Choose Setup Path

Path A (Recommended): Addressable Pixel + Postback API

• Use this if you can install the Addressable Pixel on your site.

• This is the recommended setup for campaign attribution and is the easiest to maintain.

Path B (No Pixel At All): Postback API only

• Only use this if you do not have a pixel set up on your Addressable account.

• Some organizations have compliance policies that restrict tracking pixels.

• If you have a true “no pixel” policy, follow the S2S-only setup.

Important: Only use Path B if the Pixel is not installed at all and cannot be installed.

---

Path A (Recommended):

If you’re using both the Pixel and the Events API, follow this path.

Process Overview

1. Install the Addressable Pixel (Page View is automatic)

2. Capture the browser id ___adrsbl_nonce and store it with your user record

3. Send Events API postbacks with properties.user_id = ___adrsbl_nonce for attribution

Step-by-Step

— Step 1 —

Install the Addressable Pixel

First you must install the Pixel (via GTM or JS) on your website or platform, using this guide. Once installed, the Pixel manages sessions and user IDs on-site.

— Step 2 —

Capture Addressable's ID for Users

The Addressable Pixel creates a browser-side identifier stored in local storage:

• Key: ___adrsbl_nonce

Read it on page load (or early in the session):

const adrsblNonce = window.localStorage.getItem("___adrsbl_nonce");

Debug: If adrsblNonce is null, confirm the Pixel is loading and firing on that page.

— Step 3 —

Store the nonce with your user record (backend)

When you know who the user is (login, signup, wallet connect, etc.), persist:

• your internal identifier (user id / wallet / etc.)

• the latest adrsblNonce you saw for them

Example flow: (frontend → backend)

await fetch("/api/identify-addressable", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    userId: "<your-internal-user-id-or-wallet>",
    addressableUserId: adrsblNonce
  })
});

— Step 4 —

Send postbacks via the Events API (Server-to-Server)

A. Endpoint + parameters

• Endpoint: https://tag.adrsbl.io/events/prod_standard_stage/p.png

• Query params:

  • is_conversion=true|false

  • data = base64-wrapped JSON payload

NOTE: Requests must be URL-encoded.

B. Required attribution field (Pixel + API join)

In your data JSON, include:

"properties": [
  { "name": "user_id", "value": "<___adrsbl_nonce value>" }
]

This “join key” allows Addressable to attribute server-side events to the same user sessions the Pixel observed. (Addressable)

C. Required headers

Include these headers:

• Content-Type: application/json (mandatory) (Addressable)

• X-Forwarded-For: <user original IP> (mandatory) (Addressable)

• Accept-Language / User-Agent (optional but recommended: pass the user’s original values) (Addressable)

D. Use the Events API Example – Recommended

The Events API docs include a ready-to-use code example showing the correct encoding and request format. The only “Pixel + API” requirement is that your properties includes user_id with the stored nonce value.

---

Path B (No Pixel At All):

This is for organizations with a true “no pixel” policy.

Process Overview

1. Generate/choose a persistent unique user identifier (user_id)

2. Send a server-side page_view event that includes UTMs and ViewID

3. Send funnel + conversion events using the same user_id

4. (Optional) Include revenue parameters for ROAS + deduplication

Overview Callout

In this setup, you must provide what the Pixel would normally provide:

• a persistent user_id

• a page_view (site visit) event

• tracking parameters (UTMs + ViewID) so Addressable can attribute post-click and post-view

Step-by-Step

— Step 1 —

Use a persistent unique user id

Each user must have a unique identifier that persists for at least ~30 days so Addressable can correlate multiple events to the same user.

Examples:

• internal user id

• wallet address

• anonymous user id stored in your system

In Path B, user_id is your identifier. (In Path A, user_id is reserved for the nonce join.)

— Step 2 —

Send page_view via S2S and include tracking parameters

Without the Pixel, it is this page_view server-side event that enables attribution calculations.

Post-click attribution (UTMs)

When a user clicks an ad, UTMs like utm_campaign, utm_source, utm_medium, utm_content, and clickID should be captured from the page URL and reported with the page_view event. (Addressable)

Post-view attribution (ViewID)

When a user views (but doesn’t click) an ad, a unique ViewID is provided. When the user later visits/acts, include:

• user_id

• the original ViewID (Addressable)

Where do these go in the Events API payload?

The Events API provides a properties array for key/value parameters. (Addressable) In “no pixel” mode, include your tracking params in properties (examples):

"properties": [
  { "name": "user_id", "value": "<your persistent user id>" },
  { "name": "utm_campaign", "value": "<value>" },
  { "name": "utm_source", "value": "<value>" },
  { "name": "utm_medium", "value": "<value>" },
  { "name": "utm_content", "value": "<value>" },
  { "name": "clickID", "value": "<value>" },
  { "name": "ViewID", "value": "<value>" }
]

You don’t need every field every time — but whatever tracking params exist for that session should be included on the page_view. (Addressable)

— Step 3 —

Send funnel events + conversions via S2S

Report funnel events via the S2S API (examples include): page_view, button_click, sign_up, wallet_connect, conversion.

Use:

• is_conversion=true for conversion events

• is_conversion=false for everything else

Always include the same persistent user_id so events chain together.

— Step 4 —

While this is optional, it is recommended. Include revenue parameters for ROAS and deduplication

If you want ROAS + deduplication support, include revenue-related parameters such as:

• amount

• transaction_hash

• tokens_transferred or currency_exchanged

---

Troubleshooting

Events are received, but attribution is missing

• Path A: confirm properties includes { "name":"user_id", "value":"<___adrsbl_nonce>" } exactly.

• Path B: confirm your page_view includes user_id + UTMs and/or ViewID when present.

You’re not sure which path you’re on

• If the Pixel is installed and you can read ___adrsbl_nonce, you’re on Path A.

• If Pixel cannot be installed due to policy, you’re on Path B.