Destination

A Destination is custom code that behaves like one of our built-in channels. It runs at event time on the EdgeTag edge, at page load in the browser, and optionally via a cron. It can call third-party APIs, read and write your identity graph, store data in its own database, and expose HTTP endpoints on your domain.

Use a Destination when you need something that isn't covered by the channels EdgeTag ships with. Typical examples include forwarding events to an in-house analytics tool, building a warehouse webhook, or exposing a first-party /api/subscribe endpoint backed by your own database.

If you're modifying events flowing through existing channels (dropping, renaming, enriching), use a Transformation instead. Destinations are for creating new integrations.

What's in a Destination

A Destination is made up of a small set of stage files and, optionally, custom HTTP endpoints:

• Edge files — edge/init, edge/tag, edge/user, edge/scheduled. Run on the EdgeTag edge (Cloudflare Workers) at their respective lifecycle points.

• Browser files — browser/init, browser/tag, browser/user. Run in the visitor's browser alongside the EdgeTag SDK.

• CDN APIs — browser-callable HTTP endpoints on your EdgeTag domain.

• Server APIs — authenticated server-only HTTP endpoints, with access to the current user.

Only the files you actually write are invoked — leaving a file empty skips that stage entirely.

File Structure

Capabilities at a glance

From Destination code, you can:

• Make outbound HTTP requests through params.requestHandler

• Read and write the EdgeTag identity graph via params.userSave, params.userGet, and params.providerSave

• Persist state in a D1 database, KV store, R2 bucket, or Analytics Engine dataset

• Run scheduled jobs on a cron

• Load and initialize third-party scripts in the browser, with full consent awareness

• Expose custom HTTP endpoints (authenticated server APIs and browser-callable CDN APIs) on your EdgeTag domain