These are the most common status codes given by the HTTP-in API.
200 OK
A standard response for successful HTTP requests. The response body is usually defined in a workflow, depending on what process you are triggering.
202 Accepted
It is commonly given when a workflow is successfully triggered, but the process takes too long to process and times out. While this is a successful response, it might be a good idea to troubleshoot your workflow to ensure that it is working as intended.
To increase the time-out, include the header “processing-time-out” in the request, specified in ms. For example, “processing-time-out”: “15000”.
404 No channel was found matching the request
The request reached Bosbec, but no channels could be found. Make sure that the channel is properly configured and that you are sending requests that match the configuration, i.e., using the correct URL or method.
503 Channel was accepted, but no matching triggers were found.
This response is given when your request matches a channel but no triggers match the request. It usually indicates that the workflow might be inactive or that something is wrong with the path or trigger configuration.
Note that the HTTP-in API default status codes are based on the channels, not the workflows or triggers (unless specifically configured).
A channel will not generate 401 Unauthorized for incorrect authorization details, or 400 Bad Requests for faulty content, to allow the workflows to handle other systems’ quirks. Instead, build this type of response in the workflow.
Channel defaults
Other than these, you can set up your own default responses for a channel in the case that a request matches the channel, but no response is configured in the workflow. To do this, edit the channel and click on “Add a default response.”
From there, select the status code and any heads or content you want to use as the default.
Responses in the workflow
You can set up your own responses at different stages of the workflows in a few ways, but the most straightforward way is to use the “Send API response” job.
Adding such a job after specific routes can help indicate if everything went as expected, or content can be added to pinpoint what went wrong so that you can troubleshoot the process more easily.