API v2

A Workflow that contains an HTTP Receive and an HTTP Respond step will be published as an HTTP endpoint. The parameters on the receive step control the HTTP method and URI template along with parameters that should be extracted from path segments and query values.

HTTP Receive and Respond steps offer separate methods for stream, array and object schemas to enable different types of request and response bodies to be interacted with.

Build the HTTP interface

  1. Add the supported HTTP Receive Step at the start of the Workflow.
  2. Configure its HTTP method, route, request headers, and request body contract.
  3. Map the received values into the Steps that implement the operation.
  4. Add one matching HTTP Respond Step at the root level.
  5. Configure its status, headers, and response body.
  6. Preview and Debug the Workflow with controlled inputs.
  7. Save and publish it to the target Environment.
  8. Enable the Workflow in that Environment.

See Publish a Workflow as an HTTP Endpoint for the complete procedure.

Routing and authorization

The request hostname selects the Site Environment before Flowgear matches the Workflow route. The published revision, enabled status, Connections, and API Key must all apply to that Environment.

Use Token Authentication for service-to-service callers. Embedded Apps can use Cookie-based Authentication for permitted signed-in users.

Browser access

Configure exact origins under the target Environment's Allowed origins. Flowgear supplies the CORS response at the Environment boundary. Do not add platform-managed Access-Control-* headers inside the Workflow.

OpenAPI and troubleshooting

OpenAPI is generated from the published HTTP receive and respond contract. It does not publish, enable, or authorize the Workflow.

See also

See Export OpenAPI Definitions, CORS and Allowed Origins, and Troubleshooting API Binding.