Policies

A — inbound, because the whole point is to stop a bad request before it costs anything. Inbound runs first; a failed token check there returns a 401 and the backend never hears the request, which is both cheaper and safer. B misunderstands the front desk: the backend may also check (defence in depth, 38f), but relying on it alone means unauthenticated traffic reaches it, which is exactly what the gateway exists to prevent. C is too late — outbound runs after the backend already answered, so you would have served the request before deciding it was unauthorised. D confuses a control with error handling: on-error decides what a caller learns when something breaks, not whether they were allowed in. The pipeline order is not trivia; it is what lets a gateway reject cheaply.

B — CORS is a browser rule, not a server one. A browser will not let a page at one origin read a response from another unless the API says that origin is allowed, and it checks by sending a pre-flight OPTIONS first. curl obeys no such rule, which is why the exact same request succeeds from the terminal and fails from the page — the classic symptom that tells you it is CORS and not auth or availability. The fix is a cors policy naming https://shop.campux.co as an allowed origin and the methods it may use. A and C invent failures the symptom rules out (curl works; the key is fine). D reaches for the wrong layer entirely — CORS is not a port or firewall matter, and "just open it" here means allowing every origin, which hands your API to any hostile page.

Limit, authenticate, cache-and-strip — traffic work, every one. The test all three pass: they concern how requests flow, not what the application means, and they apply uniformly across the operations behind the gateway. The rejects fail it from opposite directions. Discount rules in policy expressions is business logic hidden in XML — outside the debugger, outside the test suite, outside the repo review path most teams wire for application code — and six months later a pricing bug hunt ends in a place no developer thought to look. And returning raw exception detail inverts on-error's whole purpose: stack traces, connection-string shapes, and library versions are a reconnaissance packet, and "easing partner debugging" is what correlation IDs and the developer portal are for. The boundary sentence: the gateway decides whether and how a request travels; the backend decides what it means.

Line three — and notice it is defended with a real-sounding benefit ("fast at the edge"), which is how this mistake actually ships. A loyalty discount is what a price means, not how a request travels — it is application logic, and putting it in policy XML exiles it from the debugger, the test suite, and the code-review path the rest of the pricing code lives in. When the discount is wrong six months later, the bug hunt combs the backend for a rule that turns out to live in a gateway policy nobody thought to open. "Close to the edge" is a genuine performance idea that belongs to caching, not to relocating business rules. The distractors are the policy working: per-key limits and quotas are textbook gateway work (A is wrong to move them), inbound is exactly where JWT validation belongs so bad tokens cost nothing (B), and stripping headers plus caching GETs is precisely outbound's job (D). The reviewer's reflex: when logic is justified by speed, check whether it is really meaning being smuggled out of the backend.

In the moment, let the fix stand. During a live incident, unblocking the partner is the right call, and insisting on a pull request while revenue burns is exactly the "root cause before mitigation" mistake Class 36 warns against. So the immediate answer is yes — make it live. The discipline is not about the emergency; it is about what happens at 9am.

After, name what the portal edit actually created: an environment no file describes. The gateway now behaves in a way the repo does not capture, which means the next deploy from the pipeline will silently revert the fix — the partner breaks again, and nobody connects it to a deploy because the change that vanished was never in a diff. Portal drift is not a tidiness preference; it is a latent outage with a delay timer. "Later" is where that timer hides.

So make "later" a step in the incident, not a good intention. The postmortem's action item is concrete: reproduce the portal change as XML in the repo, open the PR, and deploy it through the pipeline so the live state and the file agree again — before the incident is closed. Wire a check, if you can, that flags portal edits so drift is visible rather than discovered. The sentence to leave them with: the portal fix saved the partner tonight; putting it in the repo tomorrow is what stops the next deploy from un-saving them.

Walk the stages in order, because the order is the point. "A request hits inbound first — that's where I authenticate it, rate-limit it, and shape it, so a bad or unauthorised call is rejected before the backend spends a cycle. If it passes, backend policies handle the forwarding — retries, timeouts. The response comes back through outbound, where I strip internal headers and cache. And underneath all three is on-error: anything that fails, at any stage, lands there." Naming inbound-first shows you understand why a gateway is cheap to say no with.

Then point at the red rail, because that is the senior detail. "The stage most people skip is on-error, and it is the one an auditor reads first. What it returns is the difference between a clean 429 with a Retry-After and a raw stack trace that leaks the backend's shape, library versions, and maybe a connection string. I keep on-error terse for the caller and detailed only in the logs — a correlation ID out, the forensics kept in the Class 28 workspace."

Close on where teams get it wrong: the boundary. "The recurring mistake isn't in the pipeline mechanics — it's people smuggling business logic into policy XML because it feels fast at the edge. Then a pricing bug lives somewhere no debugger looks. My rule is that policy stays traffic-shaped — auth, limits, caching, transforms — and anything about what the request means stays in the backend. Also: policies are code, so they live in the repo and ship through the pipeline, not the portal." Those two disciplines, said out loud, are what separate someone who has run an APIM in production from someone who has clicked through the portal once.