The Request Lifecycle is the ordered pipeline every call passes through from the moment a client sends a request to when the response is returned — and the HTTP status codes that mark where a failure stopped it.
Overview
When a client calls one of your managed APIs, the platform runs it through a fixed seven-step 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 six stages run in order, and any failure stops the pipeline there:
Apply inbound policies — rate limits, IP control, CORS, and pre-flight checks.
Authenticate & Authorize — validate the caller's credentials, resolve them to an access profile, and confirm the profile is allowed to call this endpoint.
Match the route — find the endpoint whose path and HTTP method match the request.
Invoke the backing resource — run the automation, LLM, external API, or event stream.
Build the response — optionally serve from cache, apply outbound policies, then return.
Record metrics for the Insights dashboard.
Inbound Policies
Policies run first, before credentials are checked. The platform applies inbound policies in order: access-profile policies first, then endpoint, then collection. A policy that rejects the request stops the chain immediately. Common inbound results include 429 Too Many Requests (rate limit or quota exceeded) and 400 (request validation failed). Any limit counted for a rejected request is rolled back so it is not held against the caller's future allowance.
Authentication & Authorization
After policies pass, 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.
Once the caller is identified, the platform confirms they are allowed to reach this endpoint:
The endpoint must be active — an inactive endpoint returns 403 Forbidden.
The access profile must include the collection (and the specific endpoint, if the profile restricts to certain endpoints) — otherwise 403.
Any IP-based access rule must allow the caller's IP — a blocked IP returns 403.
Routing
After authentication and authorization the platform matches the incoming URL path and HTTP method against the collection's endpoints. Path templates with variables — like /orders/{"{id}"} — match real paths (/orders/123) and capture the variable. If the path matches an endpoint but the method is not one it supports, the caller gets 405 Method Not Allowed; if no endpoint matches the path at all, they get 404 Not Found.
Resource Invocation
Only after all five preceding steps pass does the platform invoke the backing resource. The call is bounded by the endpoint's timeout; exceeding it returns 408 Request Timeout. If the resource errors, the endpoint can retry, then fall back to a configured fallback response; otherwise the caller receives 500. On the way out, a successful response may be cached (flagged with an X-Cache header) and outbound policies are applied before it is returned.
Response Code Reference
Status | Stage It Comes From |
|---|---|
401 Unauthorized | Credentials missing or invalid (authentication). |
403 Forbidden | Authenticated but not allowed — endpoint inactive, collection or endpoint not in the profile, or IP blocked. |
404 Not Found | No endpoint matches the path. |
405 Method Not Allowed | The path matches an endpoint but not for that HTTP method. |
408 Request Timeout | The backing resource exceeded the endpoint's 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 X-Cache header. |
Notes
Read the response code before debugging — it tells you which stage to look at first.
A 401 always means credentials; a 403 always means access configuration.
Set a meaningful timeout per endpoint — the right value depends on how long your backing automation typically takes.
Configure a fallback response on endpoints where callers should receive a graceful answer even if the automation fails.
Inbound policies are evaluated in order: access-profile → endpoint → collection. The first rejection stops the chain.