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 supports multi-line content for easy formatting.

Sending binary content (BLOB / Media fields)​

If the entire body is a single placeholder pointing at a binary source — a BLOB field, a Media field, a MediaSet, or a Media Reference — 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.

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.

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

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.