Webhooks in and out

Requirements: a role that can manage automations, and access to configure the other system.

Not every tool you use has a ready-made connector, and waiting for one is not much of a plan. Webhooks are the general-purpose route in both directions: something happens elsewhere and Sonta reacts, or something happens in Sonta and another system hears about it.

Incoming: an outside system starts an automation

An automation can be triggered by an incoming request. Sonta gives that automation a private address; anything posting to it starts the run, and the data sent along is available to the steps that follow.

This is how you handle events Sonta has no way of knowing about on its own — a payment cleared in your billing provider, a form submitted on a tool you use, a delivery status changed by a courier. The other system does not need to understand Sonta; it only needs to be able to call an address when something happens.

Two protections matter. The address is unique and should be treated like a password — anyone holding it can start that automation. And you can require a shared secret, so a request that does not carry it is refused. Use both: a webhook address in a public repository is an open door.

Outgoing: an automation calls another service

In the other direction, an automation step can call an external service. You give it the address to call, and if the receiving system needs specifics you can set the method, add headers — an API key, an authorization token — and shape the body it receives, including values from the record that triggered the run.

This covers the long tail neatly: post to a team chat, push a record into a warehouse system, notify a legacy tool that will never have a connector of its own.

Retries

Outgoing calls can carry a retry policy, because networks fail and services have bad minutes. This is worth setting for anything that matters — a failed notification that silently vanishes is worse than one that arrives late.

One constraint to know: retries apply to outgoing calls and record-changing steps, and are not available on steps inside a loop. If you are calling a service once per record in a batch and need resilience, do the work in a separate automation the loop calls, rather than expecting retries inside the loop itself.

Notes and limitations

• Treat an incoming address as a credential — anyone with it can start the automation. Require a shared secret as well.
• Outgoing calls can set method, headers, and body, and can include values from the triggering record.
• Retries are unavailable inside a loop — move the call into a sub-automation if you need them per item.
• A webhook trigger has no record attached — the incoming data arrives as payload, so steps must look up any records they need.
• The receiving system decides what it accepts — shape the body to what it documents, not to what seems natural.

Related

The trigger side is covered in automation triggers; building and testing the automation itself in create and activate an automation. For services that do have ready-made connections, see integrations overview.