Skip to main content
The endpoint behind identify() and track(). Use it directly when the tag isn’t an option. For an ordinary web page, use the tag — it handles the consent gate, batching, buffering and identity for you.

​
The request

​
One event

There’s no timestamp field, and one won’t be accepted. allGood records when it received the event; a caller-supplied time would let any site running the tag write arbitrary history. Source and request metadata are stamped by allGood and never read from your body — that’s what stops one caller claiming to be another account’s traffic. Under the default posture, allGood requires evidence that the visitor consented. It accepts either a valid identity cookie on the request, or X-AG-Consent: granted. On a page allGood doesn’t serve there’s no cookie to prove it with, and the consent platform lives in the page — so under a blocking posture this header is the only thing that can carry the answer at all. It’s an unverifiable claim, and deliberately so: it’s bounded by the checks above it, an allowlisted origin presenting the account’s own key. Send it only when the visitor’s signal really says yes. If the account has No tracking before opt-in off, the header is ignored.

​
The order of checks

Deliberately mirrors the form endpoint, so the two can’t report different outcomes for the same class of problem. A revoked key refuses everything: the record is kept with its fingerprint cleared, so revocation reads as “refuse” rather than “this account never needed a key”.

​
Responses

202, not 200: these are accepted for processing, not processed. Nothing downstream is synchronous. An accepted batch also sets the identity cookie if the request didn’t carry a valid one. That’s the one place the cookie is minted for an embed — without it, every visitor on your own website would look like a new device on every request.

​
Limits

These budgets are separate from the form ones, so a flood of tracking can’t exhaust the allowance real submissions depend on.

​
Identity

One identifier per batch rather than per event is deliberate: the events came from a single visitor in a single flush, and giving each its own would invent a crowd. The cookie belongs to your allGood subdomain and isn’t readable by page script. Where your website and your allGood domain share a registrable domain it rides along with capture requests; where they don’t, it doesn’t, and each request looks like a new device. In that case $identify with an email is the only thing tying a visitor’s events together.

​
URLs

A url property is treated the same way as in the tag: attribution parameters are lifted out, personal-looking query values are removed, and path and host are added. Because the request goes to your allGood subdomain, allGood can’t infer which page the visitor is on. Sending properties.url is how you tell it.

​
What this endpoint is not

  • Not a webhook receiver. Third parties can be pointed at it, but they need your tracking key and there’s no signature verification.
  • Not a query API. It’s write-only. Read your activity data through allGood’s database and warehouse surfaces.