Webhook

Use the Webhook trigger when you want a flow to start in response to an HTTP call from outside Business Central – a third-party callback, a custom integration, a Slack bot, anything that can call a URL. The flow can run fully asynchronously (the caller gets an immediate response) or synchronously up to a Respond to Webhook step (the caller waits for your flow's response).

Typical examples include:

• Receiving a payment-gateway callback and updating the matching invoice.
• Letting a partner portal trigger a sales order import.
• Acting as a bridge that transforms an inbound payload and forwards it to another system.

Requires AutoFlow Premium

The Webhook trigger is a Premium feature. The environment you publish the flow to needs an active AutoFlow licence of Premium or higher (Premium, Ultimate, or Unlimited). Starter and the free tier can build a webhook flow, but it will not go live until the package is upgraded. See Licensing below.

Business Central Online only

The Webhook trigger relies on the AutoFlow webhook proxy to reach your environment, so it works on Business Central Online (SaaS) only. On an on-premises installation the trigger cannot be configured – opening its configuration tells you “The webhook trigger is only available on Business Central online (SaaS). It cannot be configured on-premises.” and no endpoint is registered. To start a flow from outside an on-premises Business Central, use a scheduled flow that polls, or call the flow through a Business Central web service of your own.

Licensing

Inbound webhooks are available from the AutoFlow Premium package upward. The check is on the environment's assigned licence, not the individual user – whoever publishes the flow, the target environment must hold at least Premium.

Sandboxes are exempt. You can build, publish, and test a webhook flow on a sandbox environment on any package – so you can try it out before it goes live in production. The Premium requirement applies only when the flow is published to a production environment.

What you see if the environment isn't licensed for it: publishing the flow still succeeds (nothing is lost), but the flow card's Registration status shows “The webhook trigger requires at least AutoFlow Premium.” and the endpoint is not registered – calls to it will not reach the flow.

To enable it: upgrade the environment's package to Premium (or higher) in the AutoFlow portal, then republish the webhook flow. On the next publish the endpoint is registered and the status flips to Registered – the webhook is live.

An existing, already-live webhook keeps running for the remainder of a licence term; the gate applies when a webhook is published or its URL is regenerated. To keep an integration alive, keep the environment on Premium or higher.

How it works

1. You publish a webhook flow. AutoFlow registers it and gives it a unique endpoint URL on the AutoFlow webhook proxy – shown on the flow card.
2. A caller sends an HTTP request to that URL with any payload (or none). No Business Central sign-in, API key, or secret is required from the caller.
3. The AutoFlow proxy forwards the request into your Business Central and starts the flow. The inbound method, headers, query string, and body are handed to the flow as trigger outputs.
4. The caller receives your flow's real HTTP response – the status code and body the flow returns, with nothing wrapped around it. If the flow doesn't return anything of its own, the caller gets the trigger's default response.

The URL is the credential – anyone who has it can trigger the flow. Treat it like a password: send it only over HTTPS, store it in your caller's secret store, and regenerate it if it leaks.

The endpoint URL

After you publish the flow, the flow card's Webhook Call section shows the Endpoint URL. It looks like this:

https://webhook.autoflow365.app/<org>/<id>

• Where to find it: open the flow, look at the Webhook Call section, and copy the Endpoint URL into your caller. It appears once the flow is published.
• It is unique to this flow and this environment. A flow copied to another environment (or duplicated) gets its own fresh URL on publish – the old one is never carried over.
• Regenerate: the Regenerate webhook URL action mints a new URL and immediately stops the old one. Use it if the URL leaks or you want to rotate it.

Allowed HTTP methods

In the trigger configuration you choose which HTTP methods this webhook accepts – GET, POST, PUT, PATCH, DELETE. A request that uses any other method is rejected by the proxy with 404, exactly as if the URL didn't exist, and nothing reaches Business Central.

Enable only the methods your caller actually uses. Locking the list down keeps the endpoint's surface small and makes accidental calls fail cleanly.

What the flow receives

The trigger exposes the incoming request to the rest of the flow as four outputs:

Output	Description
Payload	The raw request body, exactly as the caller sent it (usually a JSON string). Parse it with the JSON steps or read values with SmartFields.
Method	The HTTP method of the call (GET, POST, …).
Headers	The request headers as a JSON object (a string), e.g. to read a custom X-… header.
Query	The raw query string from the URL (everything after ?), if any.

Responding to the caller

Whether the caller waits for your flow – and what they get back – depends on the trigger's Response Mode.

• Instant return (default): the caller receives the default response immediately and the flow runs in the background. Use this for fire-and-forget integrations.
• Wait for Response step: the trigger holds the caller's HTTP request open until the flow reaches a Respond to Webhook step (or the Sync Timeout fires). Use this when the caller needs synchronous feedback from the flow.

caution

Sleep and other time-based deferral steps must appear after the Respond to Webhook step in the flow. The synchronous response window cannot be paused – a deferral before Respond will surface as an error to the caller.

The Respond to Webhook step

In Wait for Response mode, the Respond to Webhook step (from the Essentials palette) is what unblocks the caller. Add it wherever you want the caller to get their answer – usually as early as possible, with the heavy work queued behind it. When it runs:

1. The runner evaluates the configured Status Code, Content-Type, and Body (with SmartFields and SmartFormulas resolved).
2. Those become the caller's real HTTP response.
3. The runner exits the synchronous window. Any steps after Respond to Webhook continue asynchronously – the request is already over from the caller's perspective.

If the flow finishes (or hits the Sync Timeout) without ever reaching a Respond to Webhook step, the caller receives the trigger's Default Response Status Code and Content-Type with an empty body.

In Instant return mode the step is a no-op: the caller already received the default response before the flow started, so any Respond to Webhook step is ignored.

Typical patterns:

• Acknowledge first, work later: return {"received": true} immediately, then do the slow downstream work asynchronously.
• Synchronous validation: run a quick check and return a verdict (e.g. 422 with {"approved": false, "reason": "..."}) to a partner portal.
• API bridge: forward a transformed payload to another system and return that system's reply as the webhook response.

Configure the Respond to Webhook step

• Status Code – the HTTP status returned to the caller. Range 200..599 (1xx codes are rejected). Use 200/201 for success, 4xx for caller errors (422 for validation), 5xx for backend problems.
• Content-Type – the MIME type of the body. application/json is the most common; use text/plain for diagnostics, application/xml for SOAP-style replies.
• Body – the response body. Supports SmartFields and SmartFormulas, so you can compose it from upstream step outputs.

Registration and status

Publishing a webhook flow registers it with the AutoFlow portal and provisions the connection into your Business Central. The flow card's Webhook Call section reflects the state in its Registration status field – click it to take the next step when one is needed:

Status	Meaning
Registered – the webhook is live.	The endpoint is registered and calls reach the flow. Nothing to do.
Registration pending – click to retry.	The portal was unreachable at publish time. Click to retry, or just republish.
Administrator consent required – click to grant.	A Business Central administrator must grant consent for AutoFlow to receive calls into this tenant (a one-time step per tenant). Click to check and open the consent page.
Requires at least AutoFlow Premium.	The production environment isn't licensed for webhooks. See Licensing.

Permissions – the webhook user

An inbound webhook has no signed-in user, so the flow runs as a dedicated webhook application user. AutoFlow grants that user the permissions the flow engine needs automatically. If a step in your flow reads or writes other data – custom tables, or data owned by another extension – you must grant that access to the webhook user yourself.

Use the “Assign required permissions to the webhook user” link on the flow card to open that user and add the permission sets the flow needs. If a step fails for a missing permission, it is recorded in the flow's execution log so you can see exactly what to grant.

Configure the trigger

Open the flow editor, pick When a webhook is received, and complete the configuration card.

• Description – state what triggers this flow. Shows up in trigger lists and execution history.
• Allowed HTTP methods – the methods this webhook accepts (see Allowed HTTP methods). Enable at least one.
• Response Mode – Instant return or Wait for Response step (see Responding to the caller).
• Sync Timeout (seconds) – how long the synchronous phase of a Wait for Response call may run before the caller receives the default response and the flow continues in the background. Default 30 seconds; visible only in Wait for Response mode.
• Default Response Status Code / Content-Type – what the caller sees when the flow ends without reaching a Respond to Webhook step (timeouts, no Respond at all, or Instant return mode). Defaults: 200 and application/json.

Sample call

curl -X POST \
  "https://webhook.autoflow365.app/<org>/<id>" \
  -H 'Content-Type: application/json' \
  -d '{ "customerNo": "C-001", "name": "Acme" }'

The response is the flow's real HTTP response. With a Respond to Webhook step returning 201 and a JSON body, the caller sees exactly that:

HTTP/1.1 201 Created
Content-Type: application/json

{"ok":true}

No envelope, no wrapper – the status line and body are the flow's own.

Errors the caller may see

These come from the proxy, before or around your flow:

• 404 – the URL is unknown, has been regenerated or purged, or the request used a method that isn't in the allowed list. (All four look identical on purpose – an unknown URL gives nothing away.)
• 502 – the flow raised an error, or Business Central couldn't be reached.
• 504 – the synchronous phase ran past the Sync Timeout and Business Central didn't respond in time.

Any other status (200, 201, 422, …) is your flow's own response.

Best practices

• Treat the URL as a secret. It is the credential – use HTTPS only, keep it in your caller's secret store, and Regenerate it if it leaks.
• Lock the methods down. Enable only the HTTP methods your caller uses; everything else returns 404.
• Respond fast. In Wait for Response mode, place Respond to Webhook early so the caller isn't blocked by slow downstream work; long-running steps go after it.
• Pick deliberate response status codes. Don't reuse 200 for failure cases – 4xx/5xx make caller-side error handling tractable.
• Grant the webhook user what it needs. If a step touches data outside the flow engine, assign that access to the webhook user; a missing permission shows up in the execution log.
• Keep the environment licensed. A production webhook needs AutoFlow Premium or higher; a downgrade stops new registrations.