← Back to Labs
API Gateways
Trace how a gateway admits the public request, verifies identity, selects a route, rewrites trusted context, and protects internal services from unsafe traffic patterns.
Request
State
POST /v1/payments/authorisations
{"orderId":"ord_9812","amount":1299,"currency":"EUR"}
Write path with idempotency expectations downstream and tight timeout control at the edge.
Normal routing, warm caches, and healthy upstream latency.
Route decision
api.example.eu/v1/payments/authorisations -> payments-authorise-v1 -> payments-v1
Policy decision
tenant_athens_19 · payments:write · payments-write costs 3 units
Response path
Expected response path: stable payment write with trusted context propagation and downstream idempotency support.
Internal request headers
POST /internal/payments/auth HTTP/1.1 Host: payments.prod.svc.cluster.local X-Consumer-Id: tenant_athens_19 X-Required-Scope: payments:write X-Quota-Descriptor: payments-write X-Request-Id: gw-01JY6R4P4Q8DMB6Q0VCSM5J8F4 Traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 X-Idempotency-Key: 4b7d1f34-2f48-4cd4-a9ff-b4d3f51690a2
Decision log fields
route=payments-authorise-v1 consumer=tenant_athens_19 auth=allowed via JWT plus merchant claims quota=payments-write:3 upstream=payments-v1 retry_count=0 unless downstream contract says replay is safe
Step 1 / 6Edge admission
The public client talks to the gateway first. TLS, header limits, and the initial route match happen here before any internal service sees the request.
Arrow keys to navigate · R to reset
Tap dots to jump to any step