Skip to main content

HTTP Request

Use the HTTP Request step whenever your flow needs to call an external API, webhook, or web service. It’s the go-to action for integrations: fetch data from a partner system, push updates to a third-party app, or trigger downstream automation outside Business Central.

Typical use cases include:

  • Sending order data to a shipping provider.
  • Calling a validation service to enrich a customer record.
  • Triggering a webhook in a connected portal or middleware.

Configure the step​

Open the flow editor, add HTTP Request, and fill in the configuration card.

Description​

  • Purpose: Make it clear what this call does in the flow.
  • When to fill it: Always. The description is shown in the editor and execution history.
  • Tips: Include the target system and intent, for example, POST shipment to DHL.

Credential​

  • Purpose: Reference an AutoFlow Credential to authenticate the call. The credential's authentication and any default headers are applied automatically.
  • When to fill it: Whenever the target system requires authentication. Leave empty for public endpoints or one-off requests where you'd rather type credentials manually.
  • How it works: When set, the credential's auth type computes the right headers (or query parameter) when the step runs. Auth headers are always excluded from the execution log, so secrets never leak. If the credential has a Base URL, a relative Request URL is prefixed with it (/widgets becomes https://api.example/v1/widgets).
  • Conflict handling: If you also type a manual Authorization header on the step, the credential wins and the manual header is dropped. Default Headers from the credential are applied first; manual step headers can override them; auth headers always win.

Request URL​

  • Purpose: The endpoint your request will call.
  • When to fill it: Required. Without a URL, no call can be made.
  • Tips: Use full URLs, including protocol (https://). If the endpoint is dynamic, map it from previous step outputs or variables.

Request Method​

  • Purpose: Defines the HTTP verb used to call the endpoint.
  • When to fill it: Required. Choose the verb the API expects.
  • Tips: Use GET for reads, POST for creating data, PUT/PATCH for updates, and DELETE for removals. HEAD and OPTIONS are available for special cases.

Request Headers​

  • Purpose: Add metadata the API requires (authentication, content type, etc.).
  • When to fill it: Optional, but essential for most APIs.
  • How it works: Each entry is a name/value pair. Header names are selected from the predefined header list (such as Authorization, Content-Type, or Accept).
  • Tips: Set Content-Type when you send a body, and add Authorization for secured endpoints.

Request Body​

  • Purpose: The payload you send with the request.
  • When to fill it: Available only for POST, PUT, and PATCH. In these cases you usually need to fill it.
  • Tips: Use JSON for modern APIs, and match the structure expected by the endpoint.

The body editor​

The body is written in a code editor: it highlights JSON and XML, numbers the lines, and matches brackets as you type. Which language it highlights follows the Content-Type header you set in the grid above — anything JSON-flavoured (application/json, application/problem+json) is highlighted as JSON, anything XML-flavoured as XML, and everything else is shown as plain monospaced text.

SmartFields, SmartFormulas, SmartDates and SmartControls all work here, and the buttons in the top-right corner insert them at the cursor. Unlike the single-line value fields, they stay visible as plain text — {{customer.name}}, not a rounded chip — so the payload stays valid, readable source that you can copy in and out of the step. Each one is coloured by kind, and clicking it opens the same menu you get everywhere else: replace the field, edit its formatting, change a condition, and so on. When the payload gets long, use the expand button for a full-screen editor.

Sending binary content (BLOB / Media fields, downloaded files)​

If the entire body is a single placeholder pointing at a binary source – a BLOB field, a Media field, a MediaSet, a Media Reference, or a file downloaded by an earlier HTTP Request step ({{<slug>.responseBody}}) – AutoFlow sends the raw bytes on the wire instead of a base64 string. Use this when the receiving API expects an octet-stream, image, PDF, or other binary upload:

{{invoice.attachment}}

The rule is strict. The body must be exactly one {{name}} placeholder, optionally surrounded by whitespace, with no format suffix and no other text. Anything else — a JSON envelope, a prefix, multiple placeholders, or an explicit ;base64/;utf8/;utf16 suffix — falls back to the normal text body path and the binary field is rendered as base64 inside the resolved text.

Set Content-Type explicitly when you use binary mode (for example application/octet-stream, image/png, application/pdf). AutoFlow doesn't guess the MIME type from the source field.

If you need the binary as a string inside a larger payload (a JSON envelope, a multipart part, a signed JWT), use the base64 / utf8 / utf16 format suffixes on the placeholder instead — that keeps the body in text mode and inlines the encoded value.

Test the request​

Once you've configured the step, use Test Run (in the action bar, or Ctrl+T) to send the request straight from the configuration card — no need to publish the flow and trigger it first.

Because your URL, headers, or body may reference SmartFields that only receive their values while a flow runs, AutoFlow first asks you to supplement them. It lists every SmartField placeholder used anywhere in the URL, headers, and body — one row per placeholder — and you type the value to use for the test. Each distinct placeholder is its own row: {{customer.name}} and {{customer.no}} are listed separately. For longer values, use the assist-edit (...) next to a value to open the multi-line editor (text above 250 characters is supported).

When you confirm, AutoFlow substitutes each placeholder with the value you gave it, applies the selected credential, and sends the request. This is a real, authenticated call to the endpoint — so point the test at a safe environment when the call has side effects. The response is shown so you can check the result: the status, the headers (formatted for readability), and the body. Use Copy in the top-right of the body to copy the full payload — handy for pasting into a Parser step while you build it.

Outputs​

The step returns three outputs you can use in later actions:

  • responseStatus: The HTTP status code as text.
  • responseHeaders: The response headers as JSON text.
  • responseBody: The response payload – as text, or as binary content when the endpoint returns a file (see below).

Use these outputs to branch your flow, log errors, or parse response data into business records.

Receiving files (PDF, images, …)​

AutoFlow looks at the Content-Type of the response. Text-based responses – JSON, XML, text/* and similar – are returned as text, as before. Anything else, for example application/pdf, image/png, or application/octet-stream, is kept as the original binary content.

The file stays binary in every later step. Put this step's {{<slug>.responseBody}} placeholder – on its own, with no other text – where the file should go, and it arrives unchanged:

  • a BLOB or Media field in an Insert Record or Modify Record step,
  • the body of another HTTP Request step (see Sending binary content),
  • the content of an Azure Blob Storage upload.

If the receiving API expects the file as base64 text instead, write {{<slug>.responseBody;base64}}.

If you use a binary responseBody inside text, it is inserted as base64 – that is also what a Send Email inline attachment expects. Use the utf8 / utf16 format suffixes if you need it as plain text instead, for example {{<slug>.responseBody;utf8}} in a Parser step when an API sends JSON or XML with a binary Content-Type such as application/octet-stream. The Test Run and the execution log show a short placeholder such as <binary response, 48213 bytes, application/pdf> instead of the raw bytes.

A response without a Content-Type header is treated as text.

Best practices​

  • Handle errors early: Check responseStatus and add a decision step for non-2xx responses.
  • Keep secrets safe: Use AutoFlow Credentials instead of pasting API keys, tokens, or passwords into headers. Credentials are encrypted at rest, never appear in logs, and let you change a key in one place.
  • Be explicit about formats: Always set Content-Type and Accept when the API is strict about media types.