Skip to content
DocsOpen Hub
Test & operate

Test workflows and public APIs

On this page

Use node tests to inspect one operation, full workflow tests to verify the graph, and external requests to verify the public route and access rules. Each test answers a different question.

Build a small test set#

For every action, keep examples for:

  • A valid request with a known result.
  • Missing and malformed required input.
  • Empty or missing records.
  • A caller without the required authentication or permission.
  • A failing or unavailable dependency.

Use dedicated sandbox data and test service accounts. Confirm bindings before running any operation that sends messages, changes identity, or writes to an external system.

Test an individual node#

Use the node's test controls to check its input and result. Supply representative data for required selectors. A node test does not prove that preceding nodes run or that the public gateway accepts the client.

A Database node whose entire SQL comes from a previous Function needs that Function to execute in the same run. Use a full workflow test for this mode.

Test the whole workflow#

Run a sample through the action's test panel and inspect the node sequence, outputs, and final response. Test every Condition branch and Decision outcome.

Some internal sample tools bypass IdP authentication for development and identify that mode. To test real identity behavior, use a valid bearer token with bypass disabled where supported, then verify the public route separately.

Test externally#

Use the copied sandbox URL or a generated Postman request. Match the method, path, headers, query, body, and authentication exactly. For browser apps, test from the actual origin so CORS is included.

Keep regression coverage#

Use Workflows → Test Automation for repeatable cases supported by your workspace. Assert meaningful outputs and failure behavior. Run the relevant cases when changing a shared selector, schema, authentication gate, or release dependency.

Record the environment and version used for verification. A successful build, valid JSON, or 200 response alone does not prove the correct business records were returned.

Need to investigate a problem? Start with troubleshooting