Overview

For SaaS apps where the success happens after a server-side confirmation — a payment captured, a signup verified, a booking confirmed — send it from your backend instead of the browser SDK. Ad blockers can't touch your backend traffic.

Get an API key

In the dashboard, add a success and choose "Track it from your server". Click Create API key and copy the token — it's shown once, so store it in your secrets manager. Need more than one (say, a separate key per service)? Use Add another key to create named extras.

The token looks like:

dl_live_<key_id>_<secret>

Cap of 10 active keys per site. Revoke and rotate any time.

Pick your framework

Each guide is a copy-paste example that reads the visitor's request and forwards it, so the conversion is credited to the real person — device, country, and source included.

Not listed? Any backend works — the contract below is just an authenticated POST. Use the example closest to your HTTP client.

The endpoint

POST /event
Authorization: Bearer dl_live_<key_id>_<secret>
Content-Type: application/json

{
  "event_name": "success",
  "name": "signup",
  "page_path": "/checkout/success",
  "ip": "203.0.113.42",
  "user_agent": "Mozilla/5.0 (Macintosh; …) Chrome/120",
  "success_value": 9.99,
  "properties": {
    "plan": "starter"
  }
}

Returns 204 No Content on success. Returns 401 if the token is invalid or revoked.

Fields

Credit the conversion to the visitor

A server-side success fires from your backend, which doesn't inherently know which browser visitor did it. There are two ways to connect it — pick by where the conversion happens.

In a request handler (recommended)

If the conversion runs while handling the user's request — a Server Action, a route handler — forward the visitor's IP and User-Agent from that request:

{ "event_name": "success", "name": "...", "page_path": "/...", "ip": "<visitor ip>", "user_agent": "<visitor ua>" }

We hash them exactly the way the browser SDK does, so the event lands on the same visitor — inheriting their device, country, and source. No identify(), no ids, no cookie. The framework guides above do this for you.

Forward both ip and user_agent, and pass the User-Agent through unchanged — we match it byte-for-byte, so any rewriting breaks the link. The forwarded IP is used only to compute the visitor hash, then discarded — never stored or logged.

From a webhook (no user request)

A Stripe webhook, a cron job, or any background task has no user request to forward. There, link by id instead:

1. In the browser, when the user is known, call analytics.identify("user_123") — a one-shot ping, no cookie.
2. From your server, send that same id as success_user_id.

We map the two within a 14-day window. Call identify() with a stable id (the same string for a given user), not in a loop — each new id fires one ping. Send success_user_id but never call identify(), and the conversions still group together under that id — just without device, country, or source. Skip both paths entirely and the success still counts, as a standalone visitor.

Rate limits

500 requests per 10 seconds per key, sliding window. 429 with Retry-After if you exceed. Bump the limit if you need more — email us.

PII safety

Same as the browser SDK — property keys matching email, phone, password, ssn are stripped server-side. Don't worry about accidentally including them.

What's next

• Frontend events? See the SDK reference.
• Want ad blockers to literally not see us? Set up the first-party proxy.