Publish a Workflow as an HTTP Endpoint v2

Build an HTTP Workflow around a matched receive/respond pair, publish it to the target Environment, enable it, and authorize callers with an API Key.

Design the interface

  1. Create a Workflow.
  2. Add the HTTP receive Method that matches the required body shape: Stream, JSON object, or JSON array.
  3. Set an uppercase HTTP Method and a relative UriTemplate, such as /orders/{orderId}.
  4. Define the expected object or Array shape under the receive Returns where applicable.
  5. Add validation and domain Steps after the receive Step.
  6. Add the matching HTTP respond Method at the Workflow root.
  7. Map the status code, application headers, and response body.

Test before exposure

  1. Run the Workflow in Debug with representative request data.
  2. Inspect the receive values, domain result, and captured respond values in designer logs.
  3. Test invalid input and dependency failures as well as the success path.
  4. Save the revision.

Configure the Environment

  1. Open Site settings and confirm the target Environment hostname.
  2. Add each permitted browser origin to Allowed origins, one exact origin per line. Use * only when the security consequences are acceptable.
  3. Configure the Workflow's Connections in that Environment.
  4. Publish or promote the revision.
  5. Enable the Workflow in that Environment.
  6. Create or update an API Key that targets the same Environment and assigns this Workflow.

Invoke and verify

Build the URL from the Environment hostname plus the authored route. Send the appropriate authorization and content type. Confirm the status, headers, and body, then inspect the Workflow logs.

If invocation fails, check the hostname, API-key Environment and assignment, Workflow status, published revision, route and Method, request-body shape, Cluster availability, and Connections. Duplicate enabled Method/path combinations cause a route conflict.

Download the OpenAPI definition from the Workflows or API Keys screen when a client needs a machine-readable contract.

Worked example: echo a JSON message

This example uses the HTTP HttpReceiveJsonObject and HttpRespondJsonObject Methods. It does not need an external Connection.

  1. Create a Workflow with New Workflow in the Test Environment.
  2. Add HttpReceiveJsonObject at the root and name the Step receiveRequest.
  3. Set Method to POST and UriTemplate to /examples/echo.
  4. Add a String Property named message under the receive Step's Body Return.
  5. Add HttpRespondJsonObject after the receive Step, also at the root.
  6. Set StatusCode to 200 and add a String Property named message under its Body Parameter.
  7. Set that message Property's Expression to {receiveRequest.Body.message}.
  8. Resolve Problems, save, publish, and enable the Workflow in Test. Assign it to a Service token API Key for that Environment.

Replace the example host with the Test Environment hostname. Supply the API Key through the FLOWGEAR_API_KEY environment variable in your terminal and send:

curl --include --request POST 'https://<example>.flowgear.net/examples/echo' \
  --header "Authorization: Bearer $FLOWGEAR_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"message":"Hello Flowgear"}'

Expect HTTP 200, a JSON content type, and the response body {"message":"Hello Flowgear"}. Inspect the receive and respond Steps in Workflow Logs to confirm the mapping. This tests the published route as well as the Workflow; Debug alone does not verify hostname routing or API-key authorization.

Send malformed JSON as a separate negative test and confirm that the receive Step fails. If your application requires a particular error body, design and test that contract explicitly rather than relying on the transport's default error response.

See also

See HTTP Workflow Request and Response, API Key, and CORS and Allowed Origins.