Title : Vouch request: Fred Simard — Standard Webhooks helper PR
What I'd like to work on
I'd like to land PR #N (currently a draft on my fork bobclarkdramisinfo/trigger.dev, branch feat/standard-webhooks-helper) which adds a standardWebhooks.verify helper to @trigger.dev/sdk.
This adds first-class support for verifying webhooks that follow the Standard Webhooks spec — a format already adopted by Stripe, GitHub, Slack, Linear, Shopify, Composio, Resend, Novu, and most Svix-native providers. The current verifyRequestSignature helper in the SDK only covers single-header signature schemes (Stripe/GitHub/Cal.com/Novu style), so every user integrating Trigger.dev with a Standard Webhooks provider currently hand-rolls the same ~50 lines of crypto. The new helper wraps a small spec-compliant verification function (HMAC-SHA256 over ${id}.${timestamp}.${raw_body} with v1,<base64> prefix, base64-decoded secret, multi-signature support, configurable timestamp tolerance window, all using the existing WebhookError shape).
The change is purely additive: 1 source file (webhooks.ts) extended, 1 test file added (25 cases), 1 fixture file added. No existing logic touched, no new dependencies, no API breakage.
Tracking issue: #4928
Background
I'm a freelance cloud architect (Azure / Terraform / C# / DevSecOps), working on my own OSS project DramisInfo and using Trigger.dev to orchestrate event-driven automations. The friction that this PR addresses is real for my own use case (I have a Composio integration running today that hand-rolls this exact verification) and — based on the spec's adoption curve — for many others building on Trigger.dev.
This would be my first contribution to a third-party OSS project, so I'm happy to follow the standard Trigger.dev process and to make whatever adjustments the maintainers want on the PR.
Willingness to iterate
I'm fine doing a couple of review rounds on the PR. Happy to add tests, rename exports, restructure the API shape, or split the commit if it helps merging. Just let me know what you want.
Title :
Vouch request: Fred Simard — Standard Webhooks helper PRWhat I'd like to work on
I'd like to land PR #N (currently a draft on my fork
bobclarkdramisinfo/trigger.dev, branchfeat/standard-webhooks-helper) which adds astandardWebhooks.verifyhelper to@trigger.dev/sdk.This adds first-class support for verifying webhooks that follow the Standard Webhooks spec — a format already adopted by Stripe, GitHub, Slack, Linear, Shopify, Composio, Resend, Novu, and most Svix-native providers. The current
verifyRequestSignaturehelper in the SDK only covers single-header signature schemes (Stripe/GitHub/Cal.com/Novu style), so every user integrating Trigger.dev with a Standard Webhooks provider currently hand-rolls the same ~50 lines of crypto. The new helper wraps a small spec-compliant verification function (HMAC-SHA256 over${id}.${timestamp}.${raw_body}withv1,<base64>prefix, base64-decoded secret, multi-signature support, configurable timestamp tolerance window, all using the existingWebhookErrorshape).The change is purely additive: 1 source file (
webhooks.ts) extended, 1 test file added (25 cases), 1 fixture file added. No existing logic touched, no new dependencies, no API breakage.Tracking issue: #4928
Background
I'm a freelance cloud architect (Azure / Terraform / C# / DevSecOps), working on my own OSS project DramisInfo and using Trigger.dev to orchestrate event-driven automations. The friction that this PR addresses is real for my own use case (I have a Composio integration running today that hand-rolls this exact verification) and — based on the spec's adoption curve — for many others building on Trigger.dev.
This would be my first contribution to a third-party OSS project, so I'm happy to follow the standard Trigger.dev process and to make whatever adjustments the maintainers want on the PR.
Willingness to iterate
I'm fine doing a couple of review rounds on the PR. Happy to add tests, rename exports, restructure the API shape, or split the commit if it helps merging. Just let me know what you want.