Tracking that belongs in your stack.
Explicit APIs. Signed attribution. Server-verified outcomes.
Build once. Connect the journey.
Clear inputs. Useful context. Events you can retry. Give your team an integration it can reason about.
- JavaScript, Swift, and Kotlin SDKs
- Explicit identity and consent
- Idempotent events and signed webhooks
Little details.
A bigger difference.
Use a publishable key in client SDKs and a server key on your backend. Resolve incoming links, pass consented tokens through authenticated flows, and report verified outcomes with stable event IDs.
Separate public and secret keys
Use a publishable key for consented client events and a server key for identity and financial events. Rotate keys in workspace settings.
Integrate the platforms you use
Use the JavaScript, Swift, or Kotlin SDK for links and app events. Handle Universal Links and Android App Links in your own navigation layer.
Make delivery reliable
Use stable event IDs for retries. Configure signed webhooks for downstream events, and inspect failed deliveries before retrying them.
Small calls. Useful connections.
Follow the boundary between client context and server truth.
Start at the destination.
Use a publishable SDK key to resolve the incoming link after consent.
Good questions.
Clear answers.
Can a client app report purchases?
No. Financial events and canonical customer identity require a server key. A client must send its attribution context to your authenticated backend for verification.
How should our service handle retries?
Generate one event ID for each business action and reuse it on every retry. A repeated ID with conflicting financial fields is rejected.
How do outgoing webhooks authenticate?
Each delivery includes an ID, timestamp, and HMAC-SHA256 signature. Verify the raw body and timestamp, reject stale requests, and deduplicate on the delivery ID.