Gateway logical routes: one HTTP surface, many agent backends
How logic.json routes requests by path, method, and headers to workflows, memory, or external APIs—without redeploying your gateway for every new agent.
Why logical routes exist
Agent products outgrow a single /chat endpoint quickly. You need webhooks, tool callbacks, per-customer paths, and A/B backends—all behind one TLS hostname and API key surface. Engra Gateway separates the physical deployment from logical routing rules.
Routes are declared in logic.json and evaluated per request. The Gateway overview explains how gateways bind to your Engra project.
What a route matches
Each route can match: • HTTP path patterns (prefix or exact) • Methods (GET, POST, …) • Header predicates (API version, tenant id) • Optional body shape hints for JSON payloads
First match wins unless you define explicit priority. Keep high-traffic public routes at the top of the file for predictable latency.
Where traffic goes
Targets include: • Inline workflow steps (transform, validate, fan-out) • Memory operations (wake, search, save) via gateway bindings • Upstream HTTP proxies with injected auth • Static responses for health and metadata
See route examples for copy-paste patterns used in production gateways.
Operations tips
Version logic.json in git. Use separate gateways per environment (staging vs production) so route experiments never share API keys with live traffic.
Monitor route-level errors in the console before promoting new backends. Pair gateway routes with Agent Memory when agents need durable recall across sessions.