Svix provides webhook sending, delivery logs, endpoint management, and a consumer App Portal. The App Portal lets a customer's users add endpoints, inspect deliveries, and replay events. Access is granted through a short-lived, single-use URL generated by the backend.
That link is convenient and security-sensitive. The Svix API key must stay on the backend, while the generated portal URL and its front-end token are designed to be passed to the browser. The token is scoped to an application, expires based on the configured lifetime, and carries only the capabilities granted when it was created.
The count-only probe on 2026-11-12 used sub_type=all, page 1, and page size 1. app="Svix" returned 0. title="Svix" returned 39. http.body="Svix" returned 1,228.
Search dork: `title="Svix"`.
Search link: [ZoomEye Svix title query](https://www.zoomeye.ai/searchResult?q=dGl0bGU9IlN2aXgi).
Body query: `http.body="Svix"`.
Search link: [ZoomEye Svix body query](https://www.zoomeye.ai/searchResult?q=aHR0cC5ib2R5PSJTdml4Ig%3D%3D).
The body count is broad. The title set is smaller but still requires product confirmation. Neither observation shows that an App Portal link is valid or that an API key is exposed.
The Svix API key should be read from a server-side secret store and never returned to the browser. Use a backend endpoint that authenticates the customer before it calls appPortalAccess for that customer's application. The endpoint should derive the application ID from the authenticated customer record, not accept an arbitrary application ID from the request.
This is an object-level authorization decision. A user who is allowed to manage one application should not be able to request a portal link for another tenant by changing a parameter. Test the endpoint with two customer identities and verify that each receives only its own portal.
The portal URL logs a user into the App Portal for a period of time or until logout. The underlying access call returns a single-use URL, but the resulting browser session can persist for days. Do not place the URL in analytics, referrer headers, shared chat, or support tickets.
Use the portal's read-only mode when a customer only needs to inspect deliveries. Grant endpoint-management capabilities only when the customer role requires them. Review who can replay events, because a replay can trigger downstream side effects even if the original delivery already succeeded. Set and verify token expiry. Short-lived tokens reduce the window for a leaked browser session, but they do not replace server-side authorization. Refresh the portal session through the same authorized backend path.
Consumers must verify the svix-signature header against the raw request body with the official library and return a 2xx response within the expected timeout. Validation through a parsed or reformatted body can break the signature. A receiver that skips verification accepts forged events.
Keep replay and idempotency controls in the consumer. A valid signature does not prove that an event is new. Store the event ID and make the downstream action idempotent.
Alert on portal access requests for unknown applications, backend authorization failures, repeated signature failures, and unusual replay activity. Review API-key use from new networks. If an API key is exposed, revoke it, rotate the integration, and inspect portal sessions and delivery changes made during the exposure window.