Workspace webhooks now have endpoint management and versioned payloads

Speechify webhooks now have a proper workspace-level control surface. You can manage endpoints, inspect delivery history, subscribe to a resource.action event catalog, and pin the payload shape each endpoint receives.

The old post-call webhook path was useful, but too narrow. This is the start of webhooks as an API product surface rather than a single callback field on an agent.

What changed?

Workspace webhook endpoints now have their own lifecycle and delivery model. Deliveries are listed back through the API so teams can debug what was sent, when it was sent, how the endpoint responded, and whether Speechify will retry.

Signatures also moved into one combined Speechify-Signature header. One header is easier to copy into verifier code, easier to document, and less likely to drift across products.

Versioned payloads

Each webhook endpoint can carry its own api_version. Payloads are rendered through the same version engine as the rest of the API, so an integration can receive the shape it was built for while newer endpoints move forward.

That matters for webhooks more than normal requests. A webhook consumer is usually a background service. It might not be watched every day, and it should not break because a new field shape shipped elsewhere.

Safer endpoint URLs

Webhook endpoints are now rejected at create and update time if they point at internal, loopback, or metadata IP targets. That blocks a whole class of bad URLs before the sender ever tries to deliver to them.

It is boring security in the best way: fail when the customer saves the endpoint, not ten minutes later when a delivery worker tries to call something it never should have called.

The existing Agents webhooks guide covers post-call delivery and signing. More workspace-webhook examples should land in the docs as the event catalog grows.