Latest News from the Abyssale team
Update
API
Webhook Signing Is Live
Shared by Guillaume
• August 25, 2026
Hi there,
Webhook deliveries can now be signed, so anything receiving them can verify a payload actually came from Abyssale and hasn't been tampered with in transit. It's opt-in: nothing changes for existing integrations until a workspace fetches its signing secret for the first time.
How it works
Signing is controlled through three endpoints:
-
GET /signing-secret: fetches the workspace's signing secret, minting one if it doesn't exist yet. This is the action that turns signing on for a workspace. Until it's called, deliveries go out unsigned exactly as before. -
POST /signing-secret/rotate: generates a new secret. The previous one stays valid for 24 hours, so you can roll the new secret out to your receiver on your own schedule instead of everything needing to happen atomically. -
POST /signing-secret/revoke: ends that overlap early, if you don't want to wait out the full 24 hours. Takes effect within 60 seconds.
Once a workspace has a secret, every webhook delivery carries two headers:
-
X-Abyssale-Signature: t=…,v1=…: an HMAC-SHA256 signature computed over the raw request body, along with the timestamp it was signed at -
X-Abyssale-Delivery-Id: a unique ID per delivery, meant for deduplication on the receiving end
Verifying a signature is standard HMAC verification: recompute the HMAC-SHA256 over the raw body using your signing secret, compare it against the v1 value, and check the t timestamp is recent enough to reject replayed deliveries.
SDK support
Both official SDKs support signing as of this release:
-
@abyssale/sdk1.3.0 (Node.js/TypeScript) — signing secret management plus a signature verifier, importable on its own from@abyssale/sdk/webhooksso a receiver can verify incoming payloads without an API key configured at all. -
abyssale1.1.0 (Python) — the same secret management methods and a verifier, available viaabyssale.webhooks.
In both cases, verification is pure local cryptography it doesn't call the Abyssale API, so it works even in a minimal webhook receiver that has no other reason to hold credentials.
Why it matters
Without signing, any endpoint receiving Abyssale webhooks has to trust that a POST claiming to be from Abyssale actually is there's no way to distinguish a real delivery from a forged one. Signing closes that gap: verify the header, know the payload is genuine, and use the delivery ID to safely ignore duplicates if a delivery gets retried.
Because it's opt-in, there's no migration required to keep existing integrations working. Turning it on is a single call to GET /signing-secret whenever you're ready.