Cloudflare Workers

What you need

You need permission to edit and deploy the Worker, access to Tyton’s private server SDK, and a tracking plan prepared for testing. Static files cannot safely run code that uses a server key.

Configure the Worker

1. Add TYTON_SECRET_KEY as a Worker secret in the intended environment. Do not store its value in checked-in configuration. Follow Cloudflare’s secrets guide.
2. Read the secret from the Worker environment and pass it to the server SDK. Once your application has confirmed a real business success, wait for the approved conversion call to finish. Keep verify: true while testing.
3. Deploy and test the Worker itself. Try a successful action, a failed action, and a repeated request. Check that Tyton recorded the planned tracking call before you start live tracking.

The initialization boundary is:

import { init } from '@tyton/sdk/server';

const tracking = init({ secretKey: env.TYTON_SECRET_KEY });

Here, env is your Worker environment. Initialization sends nothing. Use the server callback after confirmed business success.

Success check

Check that the deployed Worker waits for Tyton’s SDK result and logs only a safe status or reason code. queued means Tyton accepted an event for delivery. Check for sent to confirm Meta accepted the server event.

If you get stuck

Check that this deployment has the secret, that the private SDK works in the Worker, and that outgoing requests finish before the Worker’s time limit. Repeat the test against the published Worker.

Cloudflare’s waitUntil extends execution for bounded background work; it is not durable storage. For important conversions, await the result or design a durable retry job. Do not replace the shopper’s user agent or IP with Cloudflare/provider webhook headers.