Routing Scopes

--- title: "Routing Scopes" description: "Use user paths, provider names, models, and managed API keys to scope routing, access, workflows, and audit data." icon: "route" ---

Overview

Aurora uses a normalized user_path plus provider and model scope to decide which policies apply to a request. This is the core scoping system behind managed API keys, model access, usage, audit logs, workflows, and cache behavior.

Example paths:

/team/alpha
/team/alpha/service
/customer/acme/prod

Managed API keys

You can bind a user_path to a managed API key in the admin dashboard:

API Keys -> Create API Key -> User Path

When a request uses that key, Aurora treats the key's path as the effective request path.

Header override

Clients can send a path directly:

X-Aurora-User-Path: /team/alpha

If the API key has its own path, the key wins. Aurora uses the effective path for workflow matching, audit logging, usage tracking, and model access checks.

Provider names vs provider types

Provider type is the integration implementation, such as openai, anthropic, or vllm.

Provider name is the configured instance, such as openai_primary, openai_backup, or vllm_east.

Policies that target a provider use the provider name so multiple instances of the same provider type can have different behavior.

Scoped behavior

Routing scope affects:

• model access and model lists returned by GET /v1/models
• workflow selection
• usage and audit attribution
• cache policy through the matched workflow
• guardrail and fallback enablement through the matched workflow

Path inheritance

A policy scoped to /team/alpha applies to descendants such as /team/alpha/service, but not to sibling paths such as /team-alpha.

For exact workflow precedence, see Workflows.