---
title: API webhooks vs Automatizer webhooks
description: Coevera has two separate ways to call a URL when something happens. They are set up, signed and retried differently; this is how to choose.
canonical: https://developers.coevera.com/webhooks/api-vs-automatizer-webhooks/
section: webhooks
verification: schema
lastVerified: 2026-10-15
publisher: Coevera
---

# API webhooks vs Automatizer webhooks

**Answer:** Use API webhooks to mirror record changes into another system: you register them through the API, and every change arrives as a signed POST that is retried for about 24 hours. Use the Automatizer Send Webhook action when an admin needs one call as a step of a business process, with its own method, headers and body.

The two share a name and nothing else: they are configured in different places, fire on
different things and fail differently. Settings an admin sees in the Automatizer have no effect
on API webhooks, and the other way round. The comparison below comes from the published API spec
and the public GraphQL schema; the timeouts, retries and network rules come from the platform's
code.

## Side by side

|                  | API webhooks                                                                | Automatizer: Send Webhook                                                                                                   |
| ---------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Set up in        | The API: the `Webhooks` entity, REST or GraphQL. No admin screen            | The process editor, as a **Send Webhook** action                                                                            |
| Fires on         | Any of 138 [record events](/webhooks/events/)                               | The process's own trigger: a record, a schedule, a manual start or an online form                                           |
| HTTP method      | `POST`                                                                      | `POST`, `GET`, `PUT`, `PATCH` or `DELETE`                                                                                   |
| URL              | `https://` or `http://`; private networks refused                           | `https://` only, and it can hold personalisation tags; private networks refused                                             |
| Body             | Fixed: a JSON array of events                                               | Your own text, JSON or XML, with personalisation tags                                                                       |
| Authentication   | An optional HMAC-SHA256 signature in `WebHook-Signature`; no custom headers | Custom headers (a value marked encrypted is stored encrypted and masked when read back) and basic auth, its password masked |
| Timeout          | 10 s                                                                        | 10 s; redirects are not followed                                                                                            |
| Failures         | Retried up to 10 times over about 24 hours, then the webhook is disabled    | Handled per process run; see below                                                                                          |
| Who maintains it | Developers, in code                                                         | Admins, in the CRM                                                                                                          |

## Retries and repeated calls

An API webhook retries a failed delivery with the same body, so your receiver must treat repeats
as normal ([delivery and retries](/webhooks/delivery-and-retries/)).

When the platform has to retry a scheduled Send Webhook step, it reuses the result of the call it
already made instead of calling your URL again. That is best effort, so an endpoint that a
process calls should still tolerate the occasional repeat.

## The Send Webhook URL

The URL has no length limit, and percent-encoded URLs, such as Power Automate trigger URLs, are
accepted. It must be `https://` and must not point to a private network.

## Which one to use

**API webhooks** when you sync records to an ERP, a warehouse or your own app: you need every
change, signed, with retries, and you write the receiver. Start with the
[webhooks overview](/webhooks/overview/).

**Automatizer Send Webhook** when a process should call a service as one of its steps: when a
deal reaches a step, after an approval, on a schedule. An admin configures it in the CRM; see the
help centre article
[Automatizer: Using Webhook Actions](https://help.coevera.com/en/articles/3959195-automatizer-using-webhook-actions).

## Limits

- API webhooks cannot send custom headers or a body of your own, or use a method other than
  `POST`.
- The Automatizer cannot be triggered by an inbound webhook: its triggers are records, schedules,
  manual starts and online forms. To push data into Coevera, call the
  [API](/get-started/quickstart/), as the [lead from a web form](/recipes/lead-from-web-form/)
  recipe does.