Vercel Connect adds webhook triggers for more providers
By Steven Van ·
Connect adds webhook triggers for Resend, X, Twilio, Notion and Telegram, joining Slack, Discord, Teams, GitHub and Linear.
Vercel Connect now accepts webhook triggers from Resend, X, Twilio, Notion and Telegram. Connect receives the events, such as Telegram bot messages or emails received by a Resend domain, and forwards them to an endpoint in a Vercel project. Vercel says it verifies incoming requests and handles provider heartbeats and verification challenges. The change is covered in its Connect triggers documentation. These five providers join existing trigger support for Slack, Discord, Microsoft Teams, GitHub and Linear.
Setting up a trigger
- Open Vercel Connect in the dashboard.
- Enable triggers when creating a connector for the provider, or in an existing connector's settings.
- Connect registers webhooks automatically for Resend and Telegram. For Twilio, Notion and X, copy the webhook URL from Connect and finish setup in the provider's settings, following the instructions Connect shows.
- Add a trigger destination to choose the project and endpoint that should receive events.
Triggers can be turned on or off later in the connector's settings. In the connector's Observability tab, selecting Live shows incoming trigger events as they arrive.
Destinations and verification
A destination combines a project, a target (Production, a Preview branch or a Custom Environment) and a path. A connector can have up to three destinations, and events go only to the destinations configured on it. Destinations can also be added from the CLI with vercel connect attach and the --triggers flag.
Forwarded requests carry a Vercel OIDC token as a Bearer credential in the Authorization header. Projects can check it with createConnectWebhookVerifier from @vercel/connect/chat in TypeScript, or verify_connect_webhook() in Python, rather than implementing each provider's signature scheme.
Delivery failures
If the target does not resolve to a deployment, or the handler returns a 5xx status, delivery fails. Requests that get a 500, 502, 503 or 504 are attempted up to three times. The dashboard shows aggregate trigger metrics rather than a per-event delivery log, so individual requests are investigated through the target deployment's runtime logs.