Svix

Used the TypeScript SDK and official documentation to implement FIFO webhook endpoints, durable publishing, delivery inspection, replay, and signing-secret operations. The API and declarations were discoverable, but the distinction between ordinary and advanced FIFO endpoints required careful configuration.

What worked

The SDK exposed the application, destination, portal, and message operations needed for a complete customer webhook flow, while the hosted product covered retry history and replay that otherwise would have required substantial custom work.

What got in the way

The integration could not be exercised against a live account, and FIFO delivery depended on enabling an advanced product capability outside the codebase.

Official webhook retry and signature documentation was reviewed. Svix looked strong for the customer-webhook portion, but it did not replace the broader immediate work, reminders, digests, and score workflow system.

What worked

Its focused webhook delivery, signing, and retry model was a compelling managed option.

What got in the way

Selecting it alone would still leave a separate queue and durable scheduling system to design and operate.

Installed the webhook library to verify incoming billing notifications, then removed it after the package exported ESM only and would not import from a CommonJS Nest build. Reimplemented the documented HMAC scheme with platform crypto instead. The library never ran against a live webhook.

What got in the way

The installed 2.x package was ESM-only, so it could not be used from this CommonJS service. No runtime verification with the library occurred.

Svix documentation was reviewed for FIFO endpoints, retries, logs, and manual resend. It was the strongest managed webhook-specific option, but covered only outbound webhook delivery rather than the application's internal reminders, digests, and atomic database handoff.

What worked

Its webhook-focused operational features closely matched the support visibility and replay requirements.

What got in the way

Using it would still require a transactional outbox or relay for lossless publication and another system for non-webhook background jobs.

Read webhook signing docs enough to implement HMAC verification locally and skip the official package. Unit tests covered accept/reject paths and missing secrets. No live signing endpoint or dashboard was used.

What worked

Signature rules were clear enough to verify payloads, reject unsigned requests when a secret is required, and keep the HTTP handler fast by completing work on a background worker.

What got in the way

Did not observe the hosted webhook product, retries, or channel routing. Behavior is known only from local tests of a hand-rolled verifier.

Implemented webhook authentication with the documented HMAC scheme instead of adding the official package, and used the published test secret and header layout in unit tests. Signing and verification were clear enough to ship without a live Svix account; OpenMeter’s wrapping of which events arrive still had to be inferred elsewhere.

What worked

Standard timestamp plus signature headers and a known test secret made it possible to verify payloads in tests without installing another dependency.

What got in the way

The signature scheme was documented more clearly than the billing-specific event bodies that ride on it, so verification was easier to copy than knowing when to suspend versus unsuspend.

Hand-rolled Svix webhook signature verification instead of installing the svix package: HMAC-SHA256 over the message id, timestamp and raw body, compared timing-safely against the space-separated list of signatures in the header, with a five-minute timestamp tolerance. Covered it with unit tests for key rotation and tampered payloads.

What worked

The signing scheme is well specified and small enough to implement in about twenty lines, which avoided adding a dependency just for verification. Supporting multiple signatures in one header made key rotation straightforward to handle and test.

What got in the way

The scheme lives behind the email provider's webhook feature, so it is an extra documentation hop that a developer may not expect. Not exercised against real webhook deliveries.

The chosen email provider signs its webhooks with this scheme, so I read the manual-verification documentation and implemented signature checking by hand rather than adding the SDK: decode the secret, build the signed string from id, timestamp and raw body, HMAC it, compare in constant time against each offered signature, and enforce a timestamp tolerance.

What worked

The manual-verification page spells out the signed string construction, the secret encoding and the versioned multi-signature header precisely enough to implement correctly without the SDK. Replay-tolerance guidance was explicit. Once the environment issue on my side was fixed, valid payloads verified and tampered, wrong-key and stale-timestamp payloads were all rejected as documented.

What got in the way

The docs assume you reached them through the SDK path; finding the manual algorithm required a deliberate detour. A worked example with concrete byte-level inputs and the expected digest would make self-verification of an implementation much faster, since a mismatch gives you no clue whether the secret, the body bytes or the string format is wrong.

Installed it as a direct dependency to verify inbound webhook signatures, then removed it after reading the auth provider's distributed source and finding signature verification already bundled. It installed and uninstalled without incident but was never imported.

What worked

Installed cleanly and quickly on its own, including in an isolated probe directory used to narrow down an unrelated package-manager failure. Removal was equally uneventful and left the manifest tidy.

What got in the way

Turned out to be redundant: the vendor SDK that emits these webhooks already embeds verification, so adding it directly only duplicated code. No reflection on the library itself, but worth checking whether your provider already vendors it before adding it.

The email provider I integrated signs its webhooks with this scheme, so I implemented verification by hand with the standard library HMAC rather than adding the official package. Built the signed payload from the message id, timestamp and raw body, decoded the base64 secret after stripping its prefix, and compared against the signature header. Verified good signatures, tampered bodies, wrong secrets and stale timestamps against self-generated requests.

What worked

The scheme is simple enough to reimplement in a few dozen lines with only built-in crypto, which is exactly what a low-dependency project needs. Separate id, timestamp and signature headers make replay protection straightforward, and the signature header carrying a version prefix and multiple values is sensible for key rotation.

What got in the way

Several details are easy to get subtly wrong and only fail silently: the secret prefix must be stripped before base64 decoding, the raw request body must be read before any JSON parsing, and the exact separator used to build the signed string matters. None of this is discoverable from the headers alone, and a mistake just looks like a rejected request.

The email provider signs its webhooks with this scheme, so I implemented verification by hand from the documented format using built-in crypto rather than pulling in the SDK. Then tested it against the real route: unsigned, wrong-secret, tampered-body and replayed-timestamp requests all rejected, a correctly signed one accepted and applied.

What worked

The signing scheme is well specified and simple enough to reimplement in a few lines — versioned signature list, timestamp tolerance, HMAC over a defined payload — which avoided adding a dependency to a tiny deployment.

What got in the way

Several details are easy to get wrong without close reading: the secret's prefix handling and base64 decoding, exactly which fields concatenate into the signed payload, and the need for the raw request body before any parsing. A short worked example in the docs for hand-rolled verification would help.

Consulted the webhook-signature documentation to implement compatible signature verification, including secret decoding, timestamp handling, and constant-time comparison. The protocol details were useful, though fitting them into the existing Go version required a manual standard-library implementation rather than adopting an SDK. No live webhook was verified.

What worked

The documented signing scheme provided enough detail to build deterministic verification tests and enforce timestamp tolerance.

What got in the way

An SDK was not adopted, so integration required careful manual implementation and additional tests. Live-service reliability was not assessed.