How It Works

This page shows what happens to a request from ingress to response.

What this page covers

• The runtime request lifecycle
• How authentication and policy decisions are applied
• How to quickly debug by status code

Runtime lifecycle (quick view)

1. Caller sends request with X-Client-ID, X-Profile-ID, and auth header.
2. Gateway resolves published route + method.
3. Profile auth model is applied (token, jwt, oidc, mtls, or none).
4. Policy checks run (rate/quota/IP/method restrictions).
5. Workflow executes (if enabled), otherwise proxy forwards request.
6. Response is returned and written to logs/metrics.

Authentication and authorization model

Most profile-authenticated traffic uses:

• X-Client-ID: caller identity
• X-Profile-ID: access profile
• Authorization: profile auth credential (auth-type dependent)

Auth decision is followed by policy decision (collection scope, method rules, IP rules, limits).

Debug by status code

Status	Typical cause	First check
401	auth credential missing/invalid/expired	profile auth type + token/cert validity
403	caller authenticated but outside policy scope	client/profile binding + collection access
405	method blocked	allowed methods in profile/proxy
429	rate/quota exceeded	policy limits and load pattern
5xx	upstream/runtime failure	request logs + workflow branch + upstream health

Verify quickly

curl -i "https://gateway.example.com/orders/123" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: sample-client" \
  -H "X-Profile-ID: sample-profile"

Next steps

• Access Control Overview
• Workflows Overview
• Request Logs
• API Gateway