Migrating to the Router namespace

Move your integration from the legacy /api/v1 endpoints to /api/v1/router - at your own pace.

TetraFi’s trading endpoints now live under the Router namespace - /api/v1/router/quotes and /api/v1/router/orders/*. The original paths (/api/v1/quotes, /api/v1/orders/*) remain in service as documented aliases: they invoke the same implementation with the same schemas, and every alias response carries deprecation metadata so you can plan the move.

Do you need to change anything today?

No - aliases are byte-and-semantics equivalent to the Router namespace during the migration window. You’re already future-proof if both of these hold:

• Paths are configuration, not string literals. Your base path lives in one config value, so switching /api/v1 → /api/v1/router is a one-line change.
• You follow nextActions. Preflight’s submitTo field always names the current correct submission endpoint - integrations that follow the plan never hardcode an order URL.

If endpoint paths are scattered through your codebase, consolidate them behind one constant first - that refactor is the whole migration.

How the aliases behave

Calls to the legacy paths are served by the Router product - same handler, same trusted product context, no compatibility fork:

Aspect	Legacy /api/v1/quotes|orders/*	/api/v1/router/*
Implementation	Identical - one handler, one schema	Identical
Product semantics	Router (multi-source candidates)	Router
Deprecation	Signalled via response metadata	None - target namespace
Removal	Gated on announced usage thresholds - no surprise cut-off	-

Watch the deprecation metadata on alias responses (and your workspace’s deprecation notices) for the removal timeline; the alias will not disappear before a documented gate is reached.

Looking for firm-only quotes instead? The RFQ product has its own namespace - /api/v1/rfq/* - and is not an alias of Router. See the RFQ introduction for when each product fits.