Turn an incoming email into a call to your application, ticketing service, or case system. Boundry's webhook action makes the request from the workflow after the inbound event is recorded.
The New Email trigger depends on regional inbound receiving. Check the selected deployment before publishing MX or enabling this workflow. The templates below are configuration recipes, not preinstalled sequences.
Useful when your system should open a ticket or queue a review, while you keep the message body in the original regional inbox until a trusted service fetches it.
Before you start
Inbound receiving must report ready for the selected Sydney project before you publish its MX record.
Your destination must be a reachable HTTPS endpoint that you control or have reviewed.
Create a bearer-token or HTTP Basic connection if the endpoint requires authentication; do not put secrets in step fields.
Build it in Boundry
Create a sequence and choose Boundry → New Email as the trigger.
Set To address to the inbox for this integration.
Add Webhooks → Send to Webhook, choose POST and JSON, and enter the HTTPS endpoint.
Map only the fields the endpoint needs, bind its credential connection, test, and inspect the response before enabling.
Workflow template
Use these field values as a starting point, then replace the examples with resources in your own project.
New inbox message → ticket endpoint
Create a ticket using message metadata without exporting the email body or attachments.
Boundry / New Email (email.received)Webhooks / Send to Webhook (webhook)
Field mapping
To address
cases@your-domain.exampleLimits the workflow to the intended inbox.
Method and payload
POST / JSONSends a JSON request body to your endpoint.
URL
https://api.your-domain.example/inboundBoundry refuses unsafe or internal destination addresses.
Data
message_id = {{trigger.message_id}}; sender = {{trigger.from}}; subject = {{trigger.subject}}The endpoint receives just the fields mapped here.
Expected result. A successful HTTP response is recorded on the action run. Your endpoint should deduplicate requests using message_id before creating a second ticket.
Where the data goes
Boundry keeps the trigger and run record in the project region. The selected request fields leave the region when the HTTPS action calls your endpoint; its hosting and retention become part of your own data path.
