Integration · destination
Generic webhook
Signed JSON webhooks to your own systems with allow-listed fields.
How events reach Webhook
Every path ends in the same place: the policy engine checks the consent purpose this destination requires, strips what may not leave, and the worker delivers with the shared event id.
- Server API — delivered by the worker with retries, health checks, error classification and a redacted payload preview for every attempt.
What is sent
Only what you configure in the event mapping, and only after the policy engine has allowed the event for this destination.
- Event name and timestamp, mapped from Track's standard events to the platform's event names.
- The shared event id in the platform's id field, so browser and server deliveries count once.
- No vendor click ids — this destination is your own system, so attribution stays with you.
- Order id, value, currency and items for purchase-type events.
- SHA-256-hashed identifiers (e-mail, phone, external id) for matching — only with the required consent and only if captured.
- The consent state the event was collected under, where the platform accepts consent signals.
Never sent
- Raw e-mail addresses, phone numbers or names — identifiers are hashed on ingest.
- Inferred values: unknown stays unknown, nothing is guessed.
- Events collected without the purpose this destination requires.
- Secrets: tokens live in the encrypted vault and never reach the browser, the assistant or a log.
Technical facts
- Deduplication field
id— event id- Click ids
- none
- Consent purpose
- Necessary
- Pinned API version
1- Implementation status
- Implemented · verified against the vendor documentation · verified 2026-09-02
- Vendor documentation
- Track documentation
What you need
Public identifiers can be typed in chat or the wizard; secrets go through the secure credential card or OAuth and are stored encrypted.
Public identifiers
- url
- Endpoint URL (https)
Credentials
- Signing secret (generated by Track)
signing_secret— stored in the encrypted vault
Consent
Runs under the necessary purpose because it targets your own systems (controller-side processing). Identifiers are still stripped without analytics consent and click ids without marketing consent.
Setup in a few steps
The assistant runs the detailed checks. You see the milestones that need a decision from you.
Enter identifiers
Add the public IDs from the platform. Formats are validated against the vendor's documentation before anything is saved.
Connect credentials
Paste the token into the secure card or connect the account via OAuth. Secrets go straight into the encrypted vault.
Map and test
Standard events are pre-mapped to the platform's event names. A flagged test event runs through the real pipeline and shows the vendor's answer.
Publish
Review the diff, approve, publish a signed configuration version. Roll back with one click if needed.
From Tracking Knowledge
No dedicated article yet — the Tracking Knowledge hub covers server-side tracking, deduplication and consent in general.
Questions
Can I run server-only?
Yes. Choose server mode in the wizard; the vendor script is never loaded and matching relies on hashed identifiers and click ids captured by the tracker.
How are duplicates avoided?
The browser tag and the server request carry the same event id, and purchases add the order id. The worker also deduplicates repeated source events before delivery.
What if the vendor API changes?
API versions are pinned centrally with the verification date; sunset warnings appear in the destination health long before an endpoint is retired.
Connect Webhook
Set it up with the guided wizard or let the assistant do it in chat.