TurboSign Webhooks page: broken JS verification sample, wrong idempotency ID, retry/HTTPS/URL-limit errors #211

Related PRs

• docs(turbosign): fix webhook verification samples, idempotency key, retries, HTTPS and URL limit #227 (Webhooks page: samples for all six SDKs, event_id idempotency, retries, HTTPS, 10 URLs)

docs/TurboSign/Webhooks.md (on main) has a broken code sample and four statements that contradict the backend. Found while auditing claims for the YouTube how-to series.

1. JavaScript verification sample can't work (lines ~426-441)

The sample calls verifyWebhookSignature({ signature, timestamp, body, secret }) with one object. The SDK function takes positional arguments:

verifyWebhookSignature(rawBody, signatureHeader, timestampHeader, secret, options?)

(SDK/packages/js-sdk/src/utils/verifyWebhookSignature.ts:50). Anyone who copies the sample rejects every delivery with a 401. The SDK page SDKs/webhooks-javascript is correct, so this page could match it.

2. Idempotency guidance uses the wrong ID (lines 397, 541, 650)

The page says to dedupe on X-TurboDocx-Delivery-Id. The backend mints a new delivery ID on every attempt (RapidDocxBackend src/handlers/Webhook/WebhookService.ts:285, inside the retry loop), so deduping on it catches no retries. Point readers at the event's stable event_id instead.

3. Retry count (line 551)

"retried up to 3 times" implies 4 attempts. The code makes 3 attempts in total (maxAttempts: 3, WebhookService.ts:248). Line 51 ("up to 3 attempts") is right; make 551 match.

4. HTTPS (lines 83, 537)

"URLs must use HTTPS for production environments" implies HTTP is fine in development. The backend only accepts https (src/models/Webhook/IWebhook.ts:55, .uri({ scheme: ["https"] })), so local testing needs a tunnel.

5. URL limit (lines 49, 81)

The page says up to 5 URLs; the backend validates .max(10) (IWebhook.ts:61).