Receive data with a webhook endpoint
Tell the two kinds of webhook apart, generate a catch URL under Settings and Webhooks, then start an automation from data another system sends you.
The word webhook covers two opposite things in Mailsoftly, and mixing them up costs an afternoon. Outgoing means Mailsoftly posts to a URL you own, the moment something happens in an automation. Incoming means Mailsoftly gives you a URL, you point another system at it, and whatever that system sends starts an automation here.
This guide covers the outgoing side briefly, then teaches the incoming side in full: creating an endpoint, copying its catch URL, wiring it to an automation, and testing it before anyone real is involved.
Know which direction you need
Open any automation and add a step. In the picker you will find Send Webhook, in the Integration group. That is the outgoing direction: it takes a Webhook URL you supply, optional Headers you add as key and value pairs, and a Data section where you name each key and choose which contact field fills it. Every run posts that flat JSON object to your URL. Reach for it when another system needs to hear from Mailsoftly.
The incoming direction is a different screen entirely, and it is what the rest of this guide is about. Use it when the traffic runs the other way: your store, your form tool, or your own app has something to say, and you want Mailsoftly to act on it.
The outgoing action is covered in Connect integrations and the API, and how to build the automation around it in Build a welcome automation. If neither direction fits and you would rather ask for data yourself, on your own schedule, that is the REST API: see Use the Mailsoftly API.
Create an endpoint
Go to Settings, open the Advanced group in the left menu, and choose Webhooks. The page is titled Webhook Endpoints and lists every endpoint your account has. If you have never made one, it will be empty.
Choose Create New Endpoint. A confirmation appears telling you a new endpoint URL will be generated that you can send events to. Confirm it, and the endpoint appears at the top of the list straight away.
- Any member of your team can open this page and create an endpoint. It is not restricted to admins.
- Reload the page after your first endpoint. The new row is added above the empty state panel rather than replacing it, so a refresh tidies the screen up.
That is the whole creation step. There is nothing to configure yet.
Copy the catch URL and give the endpoint a name
Each row carries four things: the name, the date it was created, a Total Requests counter, and the catch URL itself. The URL looks like https://app.mailsoftly.com/catch/ followed by a long random string. Use the copy button beside it rather than retyping it.
New endpoints are named "Endpoint -" plus a timestamp, which tells you nothing a week later. Click the name to edit it in place and call it what it is, for example Storefront new order.
- Send requests as POST. Set the Content-Type header to application/json and the raw body is read as JSON, which is what you want. Form encoded posts work too, and their fields are read the same way.
- Total Requests counts every request the endpoint has caught, so it is your first check that anything arrived at all.
The random string in the catch URL is the only thing protecting the endpoint. There is no signing secret and no second check, so anyone holding that URL can post to it. Treat it like a password, keep it out of public repositories and client side code, and share it only with the system that needs it.
Point an automation at the endpoint
An endpoint on its own only stores what it receives. To make it do something, open the automation you want it to start, click the trigger card at the top of the flow, and choose the trigger from the Integration group: it reads "Trigger when data is received from a Webhook Endpoint."
Now pick your endpoint under "Select an endpoint to listen". The picker marks each one with a dot, so you can see at a glance which endpoints have already received data and which have not.
- The first step of a webhook triggered automation must be Find or Create Contact. Mailsoftly will not let you activate the flow otherwise, because the steps after it have no one to act on.
- Inside that step, choose which field of the incoming data holds the email address. That field is what identifies the person: Mailsoftly matches an existing contact on that address, and creates a new contact with it when there is no match. If it cannot find an email in the payload, nothing runs.
- Choosing the webhook trigger also unlocks the Contact Data (Webhook) group in the step picker, which is where Find or Create Contact and Update Contact live. Those two steps are hidden for every other trigger type.
- If two active automations listen to the same endpoint, one request runs both of them and the same person can receive mail from each. Keep it to one active automation per endpoint.
The endpoint has to have caught at least one request before you can map its fields, because the list of fields you choose from is built from the last payload it received. Do step 5 first, then come back and finish the mapping.
Open your automations in Mailsoftly
Send a test request before you go live
Beside the endpoint picker there is a check icon labelled Test Endpoint. It opens a panel that walks you through the whole loop: it shows the catch URL with a copy button, tells you to send the data you want to process in JSON format from your application or a tool like Postman, and then reports what arrived.
Send your sample request, then choose Check for data. When it lands you get "Request received!" and a Detected fields list showing every field path Mailsoftly found, in exactly the form you will select in the mapping step. Until then it sits on "Waiting for your first request".
- Leave the automation in Draft while you test. Only active automations enroll anyone, so a draft flow cannot email a real person by accident.
- Once the fields look right, map the email field, then activate the automation and send one more request to watch a real contact enroll.
Only the most recent payload is kept for mapping, so send the request that best represents your real traffic last. If a test request had a field your live data will not have, resend a realistic one before you map.
An endpoint that has caught even one request can no longer be deleted, and the error you get if you try does not explain why. So do your throwaway experiments on the endpoint you actually intend to keep, rather than making one to test with and expecting to remove it afterwards.
Ready to try it in your own account?
Free to start with your Google Workspace or Microsoft 365 account. No credit card required.
