svix-integration

Mode

Default to building. Use the routing table below and write the code. A request to integrate Svix is a request for working code.

Plan only when the user explicitly asks for one. "Write me a plan", "how should I approach this?", "design this before we code", "what's the architecture?" — that, and nothing weaker, sends you to <references/planning.md>, which is plan-first: no code until the plan is confirmed.

Size is not a trigger. Multi-tenant routing, an event type catalog, App Portal embedding, a migration — build them. Don't answer a request for code with a document, and don't stop to ask whether they'd like a plan first; if they wanted one they'd have said so.

One thing to say out loud while you build, without pausing for permission: replacing an existing webhook sender changes the signature your customers verify against. Their handlers break on cutover unless they re-verify with Svix's scheme. Flag that in your summary, note it in the code where the cutover happens, and keep going — see the migration guidance in <references/dispatch-questions.md> for what a cutover has to cover.

Integration routing (Building)

First, check whether Svix is already wired into the repo. Look for a Svix SDK in the language's manifest (package.json, pyproject.toml, go.mod, Gemfile, …) and for SVIX_AUTH_TOKEN in config or env files. If it isn't there, start with <references/quickstart.md> — the setup steps come before anything below. If it is, skip the quickstart; that work is done.