Reference · built on requestConnectorStreams, queues & webhooks

Svix

Applications, endpoints, messages, and delivery attempts from Svix, with resends and recoveries through its REST API.

Request accessPricing ↗

About

Svix is a hosted service for sending webhooks. Each of your customers is an application; each application holds endpoints, the URLs that receive messages. A message carries one event type, an optional eventId, and a JSON payload of up to 1 MiB. Svix dispatches it to every matching endpoint, retries on failure across eight attempts, and records each attempt's status code and response. Operational webhooks report endpoint.disabled and message.attempt.exhausted back to you. The API runs in US, EU, Canada, Australia, and India regions.

Through Fibric, an operator reads attempts and endpoint statistics and proposes a resend, a recovery of failed messages since a given time, or an endpoint change. You approve. The connector leaves a receipt naming the messages it resent.

This is a reference listing. It documents what Fibric would read from Svix and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Applications from GET /api/v1/app and their endpoints from GET /api/v1/app/{app_id}/endpoint, including disabled, eventTypes, channels, and throttleRate
  • Messages from GET /api/v1/app/{app_id}/msg, filtered by event_types, channel, tag, and a before or after window
  • Attempts from GET /api/v1/app/{app_id}/attempt/endpoint/{endpoint_id} with responseStatusCode, responseDurationMs, and a status of Success, Pending, Fail, Sending, or Canceled
  • Whether an attempt was Scheduled or Manual, from its triggerType
  • Endpoint counts of success, pending, sending, fail, and canceled from GET /api/v1/app/{app_id}/endpoint/{endpoint_id}/stats
  • Operational webhooks endpoint.disabled, endpoint.enabled, message.attempt.failing, message.attempt.exhausted, message.attempt.recovered, and background_task.finished
  • Background tasks such as endpoint.recover and endpoint.replay from GET /api/v1/background-task, with messagesSent once finished

Proposed actions

  • Target capability: propose resending one message to one endpoint with POST /api/v1/app/{app_id}/msg/{msg_id}/endpoint/{endpoint_id}/resend
  • Target capability: propose recovering every failed message since a time with POST /api/v1/app/{app_id}/endpoint/{endpoint_id}/recover
  • Target capability: propose replaying messages an endpoint never received with POST /api/v1/app/{app_id}/endpoint/{endpoint_id}/replay-missing
  • Target capability: propose enabling an endpoint or changing its eventTypes or throttleRate with PATCH /api/v1/app/{app_id}/endpoint/{endpoint_id}
  • Target capability: propose creating a message with POST /api/v1/app/{app_id}/msg, carrying eventType, eventId, and payload

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Recover a customer's endpoint after their outage

    A message.attempt.exhausted webhook names the endpoint. Once the customer's server answers again, the operator proposes a recover call since the first failure. You approve. The receipt records messagesSent.

    With Webhook Replay

  • Spot an endpoint that is quietly failing

    The operator reads endpoint stats and message.attempt.failing events and lists the endpoints whose fail count keeps climbing, before Svix disables them at 5 days.

    With Integration Health, Vendor Outage

  • Re-enable a disabled endpoint with sign-off

    After endpoint.disabled fires, the operator drafts the PATCH that sets disabled to false and a replay-missing request for the gap, and holds both for your approval.

    With Integration Health, Webhook Replay

Requirements

  • A Svix account with an environment such as Production or Staging and an API key for it; each environment has its own keys and data
  • The regional base URL matching the key: api.us.svix.com, api.eu.svix.com, api.ca.svix.com, api.au.svix.com, or api.in.svix.com
  • Event types defined in Svix, so endpoints can subscribe to specific ones and the App Portal can display them
  • For operational webhooks, an endpoint registered with POST /api/v1/operational-webhook/endpoint or in the dashboard's Operational Webhooks section
Authentication
A Svix API key from the API Access page of the Svix dashboard, sent as a Bearer token in the Authorization header; the key identifies the region's server.

Limits

  • Message payloads are at most 1 MiB. Payloads are retained 90 days by default, and payloadRetentionPeriod cannot exceed 90 days
  • Message and attempt lists cover 90 days relative to now unless before or after is set
  • An eventId is checked for uniqueness for one day only; a duplicate inside that window returns HTTP 409
  • An endpoint is disabled after all attempts to it fail for 5 days. A delivery must answer 2xx within 15 seconds to count as success

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Svix ↗

Questions and answers

What is the Svix retry schedule?
Svix tries immediately, then after 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, and a further 10 hours, for 8 attempts in all. A 2xx answer within 15 seconds counts as success; 3xx and every other code count as failure. A response header webhook-delivery: abort-message stops further attempts.
How are Svix webhooks signed?
Svix follows the Standard Webhooks specification. Each delivery carries svix-id, svix-timestamp, and svix-signature headers, aliases of webhook-id, webhook-timestamp, and webhook-signature. The endpoint secret starts with whsec_ and signatures carry a v1 prefix. GET /api/v1/app/{app_id}/endpoint/{endpoint_id}/secret reads the secret, and the secret/rotate path rotates it.
How does Svix limit delivery rate?
throttleRate on an application caps messages per second to all its endpoints; throttleRate on an endpoint overrides it. Messages over the cap queue for later delivery. If you keep sending above the cap, the queue grows and delays keep increasing. An operational webhook request.rate_limit.soft reports a soft rate limit being exceeded.
Ask about Svix

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Svix through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy