Add Webhooks To Your Product And Recover Failed Deliveries With Svix

A big customer asks whether your product can notify their system the moment an order ships. Your engineers say yes, then quote you weeks of work, because sending the message turns out to be the easy part. The hard part is retrying when the customer’s system is down, proving the message came from you, and answering support questions about what was sent and when. If you would rather buy that than build it, Svix does the job through an API, a way for software to talk directly to other software, so your product or an AI assistant can set up and send those notifications for you.

What Svix does

The notifications in question are called webhooks. A webhook is one system sending a message to another the moment something happens. Svix describes itself as an enterprise webhooks-as-a-service platform on the sending side of that market, meaning you hand it your messages through a single API and it handles delivery to your customers. It also offers an embeddable customer portal it calls the Consumer App Portal, an open source server, and adjacent products for streaming and for receiving webhooks. Svix says its hosted service runs in multiple regions and holds SOC 2 Type II, HIPAA and PCI-DSS attestations, the security and compliance reviews that enterprise buyers tend to ask about. More on the Svix website.

What you can get done

Everything here sits under one business capability in our catalog, Webhook & Event Subscription Management, with 127 operations behind it. It breaks into three jobs.

Let each customer choose where messages go

An endpoint is the web address on your customer’s side where messages get delivered. An application, in Svix’s terms, is what groups the endpoints belonging to one of your customers. Offering this means a customer can connect your product to their systems without a support ticket or a custom project, and can limit it to the events they care about.

• POST /api/v1/app/{app_id}/endpoint adds a webhook address for a customer, and can limit it to certain event types.
• GET /api/v1/app/{app_id}/endpoint lists the addresses registered for that customer.
• GET /api/v1/app/{app_id}/endpoint/{endpoint_id} shows one address, its filters and whether it is disabled.

Keep your customer list and your settings in step

Customers change their systems, leave or ask to pause. These changes are usually tiny, and they should not need an engineer each time. If your own admin screens or customer records can make these changes directly, your support team can handle them when the request comes in.

• PATCH /api/v1/app/{app_id}/endpoint/{endpoint_id} changes some settings, such as disabling an address or adjusting which events it receives.
• PUT /api/v1/app/{app_id}/endpoint/{endpoint_id} creates an address or replaces its whole configuration.
• DELETE /api/v1/app/{app_id}/endpoint/{endpoint_id} removes an address a customer no longer uses.

Find out about trouble before your customer does

Svix can also send webhooks to you about what is going on in your own account, which it calls operational webhooks. An example is being told that a customer’s address has been disabled. If that alert lands in your support queue or team chat, someone can reach out to the customer before they notice that messages have stopped.

• POST /api/v1/operational-webhook/endpoint sets up an address where your team receives those account notifications.
• GET /api/v1/operational-webhook/endpoint lists the addresses receiving them.

Workflows that put it together

A workflow is a recipe of several calls made in order to finish a real job. APIs.io catalogs 15 for Svix, and these cover the life of a customer’s webhook setup from first day to last:

• Provision Application and Send First Message creates an application, registers an endpoint, sends a message and inspects the delivery attempts. This is the onboarding of a new customer.
• Provision Application and Open App Portal creates an application and generates a one-click link into its portal, so a customer can manage their own setup.
• Endpoint Health Check sends an example message to an endpoint and reads its delivery statistics.
• Recover Failed Webhooks triggers recovery of an endpoint’s failed messages and follows the job until it finishes, which is what you want after a customer’s outage.
• Set Up Operational Webhook Endpoint registers an address for account notifications and retrieves its signing secret, which is how your system confirms a message is genuine.
• Create Ingest Source and Endpoint sets up the receiving side, for webhooks that other services send to you.
• Decommission an Application removes a customer’s endpoints and then the application itself, the tidy ending when a customer leaves.

Ask for it in plain language

Our conversational overlays for Svix map everyday questions to the operation that answers them, so an AI assistant knows which call answers which question. These are the kinds of things you can ask:

• “Which webhook endpoints are registered for one of my Svix applications?”
• “How do I register a new webhook URL for one of my applications?”
• “Is a particular endpoint currently disabled?”
• “How do I remove a webhook endpoint a customer no longer uses?”
• “How do I get notified when something happens in my account, like an endpoint being disabled?”

You can browse one in the Svix Application API phrasing overlay.

Getting started

Svix is freemium with self-serve signup, and it comes as open core, meaning an open source project alongside a commercial hosted product. So you have a real decision between running it yourself and paying someone to run it. Your developers will want the Svix documentation and the guide to API keys, which is how your software proves who it is when it connects. If you also receive webhooks from other services, look at Svix Ingest. On APIs.io, see the Svix profile, the Endpoint API, the Application API and the Event API. Before your team quotes weeks of work on webhooks, have them price this option next to building it.