Test your integration

A passing HTTP request proves one boundary. Verify the complete user journey before enabling live revenue. Keep test identities, links, and events in a dedicated workspace and label them clearly.

Client journey

1. Install the pinned SDK release from the SDK directory.
2. Start with consent disabled. Confirm no SDK tracking request or stored attribution is created.
3. Open a real active link in a normal browser or installed app.
4. Grant consent through your app's consent flow and capture or resolve the link.
5. Send a CUSTOM event with a unique stable ID. Inspect whether the SDK delivered, queued, or skipped it.
6. Find the exact event in the same workspace. Check attribution separately from ingestion.
7. Withdraw consent and confirm subsequent client tracking is skipped and local state is cleared.

A headless HTTP probe, a bot, or a privacy-suppressed request may intentionally receive no attribution token. Do not disable production safeguards just to make a smoke test appear attributed.

Trusted backend events

Authenticate your own test user and derive their stable customer ID on the backend. Send a server-key SIGNUP with the real consented click token. Check identity and attribution in the console.

Before enabling revenue, verify your payment provider's signature and event processing in its supported test environment. Confirm amount/currency conversion and persist a delivery outbox. Do not create a real charge solely to test an example.

Retry an identical event ID and confirm duplicate: true without a second event. Retry with a conflicting amount and expect 409. Verify a publishable key cannot send a financial event. Test a partial refund with a unique refund ID and the original caller event ID.

Server links

Create a link using a stable key. Repeat the identical payload and confirm the same link is returned. Change the payload under that key and expect 409. Test a missing ID and cross-workspace ID. Update the destination, verify the public route, then archive your test link.

MCP verification

Connect with a short-lived owner-issued token. List tools, inspect setup, and use the exact verification event ID supplied by the setup guide. Send that event from the real app with type: "CUSTOM" and metadata: { "source": "developer_setup" }.

Call verify_setup_event and inspect the returned evidence. A successful handshake alone does not pass this check. Confirm production link tools are absent when the token lacks that scope, then revoke the token and verify it no longer authenticates.

Webhooks and recovery

Test a valid signature, modified raw body, stale timestamp, duplicate delivery ID, and a temporary 5xx from your receiver. Confirm duplicates are acknowledged without repeating business side effects. Verify recovery from a worker restart and a delivery timeout.

Mobile matrix

Test cold and warm app opens, an app-not-installed journey, release signing, association files, consent withdrawal, network loss, and retry after reconnect. Verify real-device behavior on each platform you ship. Emulator success does not prove store-signing or association setup.

Launch evidence

Keep a sanitized record of SDK versions, deployed app/backend versions, test timestamps, event IDs, observed results, and remaining limitations. Monitor ingestion failures, outbox age, webhook failures, and usage limits after release. A checklist does not guarantee that every future dependency or customer environment will work.