developer-toolsapi_key

Svix

Svix is an enterprise-ready webhooks service that enables developers to send webhooks reliably and securely.

Verdict

Svix manages webhook infrastructure — creating applications, registering endpoints, defining event types, and sending messages. @mention it to set up webhook delivery for your product without writing retry logic or monitoring dashboards. Developers building SaaS features get the most value: you define an event schema, Svix handles delivery, retries, and logs. The MCP exposes 37 tools covering the full lifecycle — from application setup to message dispatch to endpoint deletion. You'll need a Svix API key with write permissions; read-only keys won't let you create resources. No OAuth dance, but you're responsible for rotating keys if they leak.

Common use cases

Register webhook endpoints for new customers
Send transactional events without retry code
Archive unused event types before launch
Audit message delivery logs during incidents
Provision webhook apps per environment

Integration

Vendor: Svix
Category: developer-tools
Auth: API_KEY
Tools: 37
Composio slug: svix

Tools

Create Application
Tool to create a new svix application. use when you need to register an application with specific settings.
Create Endpoint
Tool to create a new svix webhook endpoint. use after obtaining the app id to register your webhook receiver url.
Create Event Type
Tool to create a new event type or unarchive an existing one. use after confirming application context to register or revive an event type.
Create Integration
Tool to create a new integration for a specific application. use after confirming the application id.
Create Message
Tool to create a new message for a specific application in svix. use after confirming app id and event details.
Create Source
Tool to create a source for message ingestion. use to register a new source before creating ingest endpoints.
Delete Endpoint
destructive
Tool to delete an endpoint. use when you need to remove a specific endpoint after confirming its application and endpoint ids.
Delete Event Type
destructive
Tool to delete an event type. use when you need to archive or permanently expunge a specific event type after confirming its name.
Delete Integration
destructive
Tool to delete an integration. use when you need to remove a specific integration after confirming its application and integration ids.
Delete Svix Application
destructive
Tool to delete an application by its id. use when you need to permanently remove a svix application after confirming its id.
Get Application
Tool to retrieve details of a specific svix application by its id. use when you need application metadata after authenticating with svix.
Get Attempt Details
Tool to retrieve details of a specific message attempt. use after confirming app id, msg id, and attempt id.
Get Endpoint
Tool to retrieve details of a specific endpoint. use after confirming app id and endpoint id.
Get Endpoint Secret
Tool to retrieve the secret for a specific endpoint. use after confirming app id and endpoint id.
Get Endpoint Stats
Tool to retrieve basic statistics for a specific endpoint. use after confirming app id and endpoint id.
Get Endpoint Transformation
Tool to retrieve transformation settings for a specific endpoint. use after confirming app id and endpoint id.
Get Event Type
Tool to retrieve details of a specific event type by its id. use when you need to inspect an existing event type after confirming its id.
Get Integration
Tool to retrieve details of a specific integration. use after confirming app id and integration id.
Get Message
Tool to retrieve details of a specific message by its id. use when you need message metadata and status after dispatch.
List Applications
Tool to list all applications. use when you need to retrieve or paginate through your svix applications.
List Endpoints
Tool to list all endpoints for a specific application. use after obtaining the application id to retrieve its endpoints.
List Event Types
Tool to retrieve a list of all event types. use when you need to inspect available event types, optionally including their json schemas. use after authenticating the client.
List Integrations
Tool to list all integrations for a specific application. use after confirming the application id, supporting pagination via limit and iterator. use when you need to enumerate integrations.
List Message Attempts
Tool to list all delivery attempts for a specific message. use after confirming message id to debug attempts.
List Messages
Tool to list all messages for a specific application. use when you need to fetch or paginate messages after obtaining the application id.
Patch Endpoint
Tool to partially update an endpoint’s configuration. use when you need to adjust endpoint settings without full replacement.
Patch Endpoint Headers
Tool to partially update headers for a specific endpoint. use when you need to add, modify, or remove custom headers after endpoint creation.
Recover Failed Webhooks
Tool to recover messages that failed to send to an endpoint. use when you need to retry webhook delivery for failed events after identifying delivery failures.
Replay Missing Webhooks
Tool to replay missing webhooks for a specific endpoint. use when some webhooks failed or were lost and need to be resent.
Rotate Endpoint Secret
Tool to rotate the signing secret key for an endpoint. use when you need to invalidate the current secret and generate or supply a new one. call after confirming app id and endpoint id.
Send Example Message
Tool to send a test message for a specific event type to an endpoint. use after setting up an endpoint to verify its configuration.
Set Endpoint Transformation
Tool to set or update transformation settings for an endpoint. use when you need to configure or toggle an endpoint's transformation code after creation.
Update Endpoint
Tool to update an existing endpoint. use when you need to modify endpoint settings after creation.
Update Endpoint Headers
Tool to completely replace headers for a specific endpoint. use when you need to set a full new header mapping.
Update Event Type
Tool to update an existing event type by id. use after confirming event type id to modify name, description, schemas, feature flag, or archive status.
Update Integration
Tool to update an existing integration by id. use when you need to modify integration settings like name, key, enabled status, or metadata after confirming the integration id.
Update Svix Application
Tool to update an existing svix application by id. use when you need to modify properties like name, rate limit, uid, or metadata. call after confirming the correct app id.

Setup

Setup guide

11. Open your Switchy workspace and navigate to Settings > Integrations > Developer Tools. 2. Find Svix in the list and click Connect. 3. Paste your Svix API key — generate one at dashboard.svix.com under API Keys with full application and endpoint permissions. 4. Click Save; Switchy tests the key by listing your applications. 5. Open any Space and type '@Svix list my applications' to confirm the connection works. 6. To send a webhook, first create an application with '@Svix create an application named CustomerPortal', then add an endpoint with '@Svix create an endpoint for app_xyz at https://example.com/webhooks', then dispatch a message with '@Svix send a user.signup event to app_xyz with payload {email: test@example.com}'. Each step returns an ID you'll reference in the next command.

What teammates see: by default, memories from Svix are scoped to the Space (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.

Works well with

Top models

Compatibility data appears once enough Spaces have used this MCP together with a given model.

How Switchy teams use it

Not enough Spaces yet to publish anonymised usage stats (we require ≥ 50 Spaces per week).

Starter prompts

Set Up New Webhook App

@Svix create an application called PartnerPortal, then create an endpoint for it at https://partner.example.com/webhooks with event types user.created and payment.succeeded

Open in a Space →

Send Test Event

@Svix send a test.ping event to application app_2hJ9kLmN3pQ with payload {timestamp: now, source: manual_test}

Open in a Space →

Check Recent Deliveries

@Svix list message attempts for endpoint ep_4xR7sT2vW in the last 60 minutes and show me any that failed

Open in a Space →

Define Custom Event

@Svix create an event type named subscription.renewed with schema {plan: string, renewal_date: ISO8601} and description 'Fired when a customer renews their subscription'

Open in a Space →

Clean Up Old Endpoints

@Svix list all endpoints for application app_9zK3mP5nQ and delete any that haven't received a message in 90 days

Open in a Space →

Example outputs

Illustrative - representative of the model's voice and quality, not literal recordings.

Prompt

@svix list all webhook endpoints for the 'payments-api' application and show me which ones have failed deliveries in the last 24 hours

Output

Found 4 endpoints for payments-api: 1. https://prod.acme.com/webhooks/payment (active) — 3 failed deliveries 2. https://staging.acme.com/webhooks/payment (active) — 0 failures 3. https://legacy.acme.com/webhooks (disabled) — N/A 4. https://analytics.acme.com/events (active) — 12 failed deliveries The analytics endpoint appears to be experiencing persistent failures. Most recent error: 503 Service Unavailable at 2024-01-15 14:32 UTC. This example reflects typical endpoint health data; actual failure counts and timestamps will vary by your account activity.

Notes

This read-heavy example demonstrates Svix's endpoint monitoring capabilities. Requires API key with read access to applications and endpoints. The MCP can surface delivery statistics, but you'll need to cross-reference with your own logs to diagnose root causes of webhook failures.

Prompt

@svix create a new webhook endpoint at https://api.myapp.com/webhooks/user-events for the 'user-service' application, subscribing to user.created and user.updated event types

Output

Created endpoint successfully: Endpoint ID: ep_2kX9mN4pQ7vL8wR URL: https://api.myapp.com/webhooks/user-events Application: user-service Subscribed events: user.created, user.updated Status: Active Secret: whsec_3jK8nM2pQ9vL7wR (store this securely) The endpoint is now live and will receive webhook deliveries for the specified event types. This example shows a typical creation flow; your actual endpoint ID and secret will differ.

Notes

This write example shows endpoint registration in action. Side-effect: immediately activates the endpoint for live webhook traffic. You must store the returned secret to verify webhook signatures. If the event types don't exist yet, you'll need to create them first using the Create Event Type tool.

Prompt

@svix send a test 'invoice.paid' event to all endpoints in the 'billing-service' application with payload showing invoice #12345 paid $299.00, then summarize which endpoints succeeded

Output

Sent invoice.paid event (msg_4nP9mK2qR8vL3wT) to 3 endpoints: ✓ https://crm.acme.com/webhooks — 200 OK (142ms) ✓ https://analytics.acme.com/events — 200 OK (89ms) ✗ https://legacy.acme.com/billing — 404 Not Found (timeout) Delivery summary: 2 of 3 endpoints received the event successfully. The legacy endpoint appears unreachable and may need its URL updated or the endpoint disabled. This illustrative example shows how Svix tracks delivery outcomes; actual response times and status codes depend on your receiving services.

Notes

This synthesis example pairs Svix's message creation with AI reasoning to interpret delivery results. Demonstrates the full webhook lifecycle: event dispatch, delivery attempts, and outcome analysis. Be aware this sends real webhook traffic — use test applications or clearly marked test events to avoid triggering production workflows unintentionally.

Use-case deep-dives

Webhook debugging for SaaS team

When Svix MCP speeds up webhook troubleshooting in Slack

A 6-person SaaS team ships payment and subscription events to customer webhooks. When a customer reports missing events, the on-call engineer jumps into Slack, asks Switchy to check Svix delivery logs for that application ID, and gets the failed endpoint URL and retry count in 15 seconds. The MCP's Create Message and Delete Endpoint tools let the engineer replay the event or remove a broken endpoint without leaving the thread. This works because Svix already centralizes webhook state—the MCP just surfaces it faster than logging into the dashboard. If your team handles fewer than 10 webhook incidents per month, the dashboard is fine. Above that threshold, the MCP pays for itself by cutting mean-time-to-resolution from 8 minutes to under 2.

Customer onboarding automation

Svix MCP for provisioning webhooks during trial signup

A 3-person B2B startup provisions webhook endpoints for new trial customers as part of onboarding. The founder uses Switchy to script the flow: create a Svix application, register the customer's callback URL as an endpoint, and send a test event—all from a single prompt in the shared workspace. The MCP's Create Application, Create Endpoint, and Create Message tools chain together without switching contexts. This scenario wins when onboarding volume is 5-20 trials per week—enough to justify automation, but not enough to build a custom admin panel. If you're onboarding 50+ customers weekly, invest in a proper provisioning service. For the in-between stage, the MCP keeps the founder shipping features instead of clicking through dashboards.

Event schema rollout coordination

When the MCP helps product teams version webhook payloads

A 10-person product team is rolling out a new event type for order fulfillment. The PM needs to confirm which customers are subscribed to the old event, create the new event type in Svix, and notify the integration partners. She asks Switchy to list active endpoints, create the new event type, and draft the migration email—all in one session. The MCP's Create Event Type and Delete Event Type tools let her version the schema without waiting for engineering. This works when your team ships 2-4 new event types per quarter and coordination overhead is higher than execution time. If you're shipping events daily, the MCP becomes noise—just build it into your CI pipeline. For quarterly rollouts, the MCP keeps product and engineering aligned without scheduling sync meetings.

Frequently asked

What does the Svix MCP do in Switchy?

It lets your team manage webhook infrastructure through chat. You can create applications, register endpoints, define event types, send test messages, and monitor deliveries without touching the Svix dashboard. Useful when you're debugging webhook failures or setting up new integrations and want the context in your workspace thread instead of scattered across browser tabs.

Do I need admin access to connect Svix?

You need an API key with write permissions. Svix uses API key auth, not OAuth, so whoever connects it should have access to your organization's API keys in the Svix dashboard. The key will have full access to create applications, endpoints, and send messages, so treat it like a production credential.

Can the Svix MCP read webhook delivery logs?

Yes, through the 37 available tools. You can query message attempts, check endpoint health, and retrieve delivery statistics. It won't stream real-time webhook events into Switchy, but you can pull historical data to debug why a webhook failed or verify a payload was delivered successfully.

Should I use this instead of the Svix dashboard?

Use it for operational tasks during incidents or setup. The dashboard is better for browsing delivery history or configuring retry policies visually. The MCP shines when you're in a Slack thread debugging a customer issue and need to resend a webhook or check endpoint status without context-switching.

Who on the team should connect the Svix integration?

Whoever owns your webhook infrastructure or has access to production API keys. Usually a backend engineer or DevOps lead. Once connected, anyone in the workspace can use it, so limit access if your Svix account manages sensitive customer data or payment webhooks.