ARTICLE

Receiving Polar.sh Webhooks with a Cloudflare Worker

Webhook events flowing into a Cloudflare Worker endpoint.

Webhook handling is how your system learns that something changed in Polar.sh. Purchases, refunds, subscription changes, and benefit events need to reach your backend before the extension can reflect them reliably.

Cloudflare Worker is a good fit for this layer in a small paid-extension stack. The same deployment can host checkout creation, webhook handling, license validation, and entitlement APIs without introducing a large server.

The first rule is signature verification. A webhook endpoint is a public URL. Do not trust a JSON payload just because it looks like a Polar event. Verify the Standard Webhooks signature using the webhook secret, then reject requests that fail validation.

After validation, route by event type. Purchase events can store order and customer records. Benefit events can update entitlements. Refund or cancellation events can deactivate access.

Webhook handlers should be idempotent. The same event may be delivered more than once. Store event identifiers or order identifiers so repeated delivery does not create duplicate repository invites, duplicate activations, or conflicting license state.

Never put Polar secrets in the Chrome extension. Checkout creation, webhook validation, and management API calls belong on the Worker. The extension should only call a narrow validation endpoint with the minimum data needed.

A webhook is not only a notification that a payment happened. It is the synchronization point that keeps billing, entitlements, local cache, and customer support aligned.

References