Troubleshooting API Binding

Here are some common errors that occur when invoking Workflows via REST API.

Response Codes

Flowgear binds Workflows based on HTTP method and URI. A common cause of this error is attempting to validate an API by opening it in a browser (which causes the GET method to be used), but the Workflow is actually bound to a different method (for example, POST).

Check you have provided a valid API Key

All requests require an API Key, so if you haven't specified one, you will always get a 404 Not Found response.

Check that the Workflow you're trying to invoke is listed under Workflows assigned on the API Key details screen.

Check the Environment that you are Invoking under

If Release Management is enabled, you may have a different version of the Workflow published to the Environment you are targeting. For example, if you are targeting the Production Environment, check that you are using the Production Hostname, and that the Method and URI you are using are the ones specified on the revision of the Workflow that is currently published to that Environment.

For example, you may have created a Workflow bound to GET /thing and pushed that revision to Production. Later, you may have changed the binding to GET /anotherthing and left that revision in the Test Environment. If you are invoking the Production Environment, you'll still need to use GET /thing, since the newer binding has not been published to it yet.

409 Conflict

Multiple Workflows share this route.

This error occurs when the request resolves to more than one Workflow. Here are some examples of conflicts:

Two Workflows with the binding GET /thing.
A Workflow with the binding GET /thing/{id} and another Workflow with the binding GET /thing/another. This is a conflict since it would be valid to route an invoke of GET /thing/another to either Workflow.
Two Workflows that have different routes in the Test Environment, but have a conflicting route in the Production Environment.

The wrong Workflow fires up when a call is made

Here are the reasons this can occur.

Caching

To minimize overhead, Workflow routes are cached in memory every minute. This means that if you have just saved or promoted a Workflow, it may take up to one minute before the new version is invoked.

You can force an immediate re-cache by attempting to open a non-existent endpoint, for example, https://yourcompany.flowgear.net/doesntexist. Note that manual re-cache can only be forced once a minute.

Incorrect Environment

Check the Context Property (v2 Runtime) or the InitData Property (v1 Runtime) on the Start Node Workflow Log to confirm which Environment the Workflow is executing under. The request hostname selects the Environment. The API Key must belong to that same Environment; it does not override the hostname.

Consider whether the Workflow is being invoked in the expected Environment (for example, Test or Production). If Release Management is enabled, it may be that the latest revision of your Workflow shows the correct route, but an older outdated route is published into the Production environment.

For compatibility, an older client can still send the legacy _profile query-string parameter. This parameter does not select an Environment. Its value must match the Environment already selected by the hostname or the request fails. Remove it from clients where possible.