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 (e.g. 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 as a Permitted Workflow in the API Key Detail Pane.

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, e.g. https://yourcompany.flowgear.net/doesntexist. Note that manual re-cache can only be forced once a minute.

Incorrect Environment

Check the InitData property on the Start Node Workflow Log to check which Environment the Workflow is executing under. Note that when invoked via API Key, the Environment specified within the API Key will be used.

Consider whether the Workflow is being invoked in the expected Environment (e.g. 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, it is also possible to specify the legacy querystring parameter _profile. It is best to remove this parameter if it is being provided. If you are not able to remove it from the consumer, confirm that the correct Environment name is being specified.