Every API call progresses through a multi-stage request pipeline, with specific HTTP status codes identifying the exact point of failure if a request is stopped
Overview
When a client calls one of your managed APIs, the platform runs it through an ordered pipeline and stops at the first step that fails. Each step can short-circuit with a specific HTTP status, so the code a caller receives tells you exactly which stage rejected the request — no guessing required.
The Request Pipeline
The steps run in order, and any failure stops the pipeline there:
Authenticate the caller — validate its credentials and resolve them to an access profile (and the client it belongs to).
Match the route — find the API in the API group whose path matches the request.
Authorize — confirm the API is active, that the access profile may call this API group and API, that any IP allow or block rule passes, and that the HTTP method is supported.
Apply inbound policies — rate limits, validation, CORS, transformations, and so on.
Check the response cache — if caching is configured and a matching entry exists, it is returned immediately without running the backing resource.
Invoke the backing resource — run the automation, LLM, external API, or event stream.
Build the response — store a successful response in the cache (when caching is on), apply outbound policies, then return it.
Record metrics for the Insights dashboard.
Authentication
First, before anything else, the platform reads the credential the client sent — a token, a username-and-password pair, or a JWT depending on the access profile's authentication method — and matches it to an active access profile. If the credential is missing, wrong, or belongs to a disabled profile, the request stops here with 401 Unauthorized.
Routing
Next, the platform matches the incoming URL path against the APIs in the API group. Path templates with variables, such as /orders/{id}, match real paths such as /orders/123 and capture the variable. If no API matches the path, the caller gets 404 Not Found.
Authorization
Once an API is matched, the platform confirms the caller is allowed to use it:
The API must be active — an inactive API returns 403 Forbidden.
The access profile must include the API group (and the specific API, if the profile restricts to certain APIs) — otherwise 403.
Any IP-based access rule must allow the caller's IP — a blocked IP returns 403.
The HTTP method must be one the API supports — otherwise 405 Method Not Allowed.
Inbound Policies
After the caller is authenticated and authorized, the platform applies inbound policies in order: access-profile policies first, then API, then API group. A policy that rejects the request stops the chain immediately and the backing resource is never invoked. Common inbound results include 429 Too Many Requests (rate limit or quota exceeded), 400 (request validation failed), and 403 (a CORS or request validator check failed). Any limit counted for a rejected request is rolled back so it is not held against the caller's future allowance.
Response Cache and Resource Invocation
If caching is configured and a stored response matches the request, it is returned straight away — marked with an X-Cache: HIT header — and the backing resource is not run. Otherwise, only after every earlier step passes does the platform invoke the backing resource. The call is bounded by the timeout; exceeding it returns 408 Request Timeout. If the resource errors, the API can retry, then fall back to a configured fallback response; otherwise the caller receives 500. On the way out, a successful (200) response is cached when caching is on, and outbound policies are applied before it is returned.
Response Code Reference
Status | Stage It Comes From |
|---|---|
400 Bad Request | A policy rejected the request — for example, validation failed or an API Filter automation failed. |
401 Unauthorized | Credentials missing or invalid (authentication). |
403 Forbidden | Authenticated but not allowed — API inactive, API group or API not in the profile, or IP blocked. Also returned by CORS failures and request validator protocol or content-type failures. |
404 Not Found | No API matches the path. |
405 Method Not Allowed | The path matches an API but not for that HTTP method. |
408 Request Timeout | The backing resource exceeded the timeout. |
429 Too Many Requests | A rate-limit or quota policy was exceeded. |
500 | The backing resource failed and no fallback response was configured. |
2xx | Success; a cached response carries an |
Notes
Read the response code before debugging — it tells you which stage to look at first.
A 401 means credentials; a 403 usually means access configuration (API inactive, scope, IP) but can also come from a CORS or Request Validator policy.
You can attach a Timeout policy at the API, API group, or access-profile level. When customization is enabled, the policy uses a 30-second default. If no Timeout policy is configured, the request is bounded at five minutes. A request that exceeds its applicable timeout returns 408 Request Timeout.
Configure a fallback response on APIs where callers should receive a graceful answer even if the automation fails.
Inbound policies are evaluated in order: access profile → API → API group. The first rejection stops the chain.