Home Api Troubleshooting API binding

Troubleshooting API binding

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

Response Code 404 Not Found

Check Method and URI Match

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've provided a valid API Key

All requests require an API Key so if you haven't specified one, you'll 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 you're 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're using the Production Hostname and that the Method and URI you are using are the ones that are actually 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.

Response Code 409 Conflict with `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 caching 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.

The Workflow is not firing up under the expected Environment

Check the InitialiationXml 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.