Smart routing boundaries

Smart routing should be documented as controlled route selection inside an approved workflow, not as a universal promise of best price, best speed, or guaranteed execution. Developers should expose route status, not route secrets.

0Link is account-gated routing infrastructure. Build against the product surface enabled for your account, and do not expose private route logic, liquidity-source identity, depth, connector behavior, or execution guarantees in customer-facing product code.

0Link product docs and API boundary

These pages explain 0Link concepts, state models, and implementation records for approved routing workflows. 0Link endpoint-level API pages are not published for partners yet; use this product documentation to understand the routing model, public boundaries, and readiness requirements.

End-to-end picture

This flow shows 0Link as infrastructure inside another approved product. The customer or operator may see a simple state such as route available, route pending, route filled, or route unavailable, while the backend keeps the durable route record needed for support and reconciliation.

Why this matters

Smart routing is valuable when it reduces manual route selection and produces clearer execution evidence. It becomes risky when product copy overstates automatic superiority or exposes private decision mechanics.

Before infrastructure like 0Link, large or complex execution often becomes a patchwork of manual decisions, one-off source checks, screenshots, and disconnected reconciliation. With a route model, the owning product can keep one lifecycle: request, preview, confirmation, execution report, and closeout.

Production contract

Boundary	What to build	Why it matters
Owning product	The route belongs to a higher-level product workflow such as a desk, OTC, pool fallback, or approved partner flow.	0Link should not become the customer-facing product by accident.
Route context	Store route request id, symbol or corridor, side, requested quantity/notional, algorithm profile, and account scope.	Support needs a durable way to identify the route without seeing private source details.
Preview state	Treat preview as indicative unless the enabled account contract explicitly defines a locked route.	Prevents stale pricing and unsupported best-price claims.
Confirmation state	Record who or what accepted the route and which terms were accepted.	Execution must be traceable and idempotent.
Execution report	Store filled quantity, status, VWAP or result metric where provided, fees where approved, and reconciliation reference.	Finance and support can close the route without private routing logs.

State model

State	What it means	Developer action
review_required	The account or workflow is not enabled for public route execution.	Do not expose a route action to the customer.
preview_available	A route can be described indicatively for the current account/workflow.	Show conservative route context and expiry/refresh behavior.
confirmed	The route terms were accepted by the owning product or authorized operator.	Persist confirmation id and idempotency key.
routing	Execution is underway or awaiting route result.	Show pending; do not infer fills.
filled / partial / rejected / cancelled	Terminal or exception execution result.	Reconcile and apply the owning product policy.

Do not collapse this state model into a single boolean. A route that was previewed, confirmed, partially filled, cancelled, rejected, or settled has different customer, support, and finance consequences.

Example implementation record

This is an application-side record shape for smart routing boundaries. It is not a public 0Link request schema. Use it to keep the owning product, support view, route state, and reconciliation record joined.

{
  "route_claim": "smart routing available for approved account",
  "allowed_copy": "Route selected from approved sources",
  "blocked_copy": "Always best price across every market",
  "status": "preview_available"
}

Worked route example

Step	Record to create	Notes
1. Create product order	`product_order_id`, account id, asset/corridor, requested quantity or notional.	The owning product remains the business source of truth.
2. Store route context	`route_request_id`, side, symbol/corridor, route type, account eligibility.	Do not store private source names in customer-visible tables.
3. Save preview	`preview_id`, availability, estimated result fields where provided, refresh/expiry policy.	Treat preview as indicative unless explicitly executable.
4. Confirm route	`confirmation_id`, accepted terms hash, accepted timestamp, idempotency key.	Confirmation is separate from final execution.
5. Reconcile report	`execution_report_id`, status, filled quantity, result metric, settlement reference.	Finance and support should start from this chain.

Data join map

The join map is what makes 0Link supportable. The owning product can change its customer experience while keeping the same route request, preview, confirmation, execution report, and reconciliation chain behind it.

Before and after

Before 0Link	With 0Link
Large orders were handled through manual source checks and spreadsheet notes.	The owning product stores route request, preview, confirmation, execution report, and closeout references.
Customer or operator copy implied hidden source behavior.	Customer and operator copy describes public route state only.
Partial fills and route failures became ad hoc support investigations.	Partial, cancelled, rejected, and unavailable routes enter named recovery queues.
Finance had to infer outcome from execution screenshots or chat notes.	Finance starts from execution report id and reconciliation reference.

Evidence to keep

Evidence	What to store
Route evidence	Route request id, preview id, confirmation id, execution report id, account/environment.
Terms evidence	Requested quantity/notional, side, symbol/corridor, limit/slippage rule, accepted terms hash.
Status evidence	Raw state history, timestamps, actor/source of state change, terminal status.
Result evidence	Filled quantity, result metric such as VWAP where provided, fees only where approved, reconciliation reference.
Support evidence	Request id, support-safe route ids, public customer label, escalation owner/contact.

Failure modes and recovery

Failure mode	Recovery
Route preview disappears before confirmation	Ask for a fresh preview and mark the previous preview as stale.
Confirmation is submitted twice	Return or reuse the same confirmation/execution chain using your idempotency record.
Execution report is partial	Apply the owning product policy for partial fills, fallback, cancellation, or manual review.
Route result cannot be reconciled	Keep the product state open and escalate with route ids and support-safe evidence.

Operator runbook

Signal	Check first	Action
Preview unavailable	Check account eligibility, supported asset/corridor, route size, and route freshness.	Hide the route or ask for a fresh preview; do not reveal private depth causes.
Customer or operator disputes result	Open route request id, confirmation id, execution report id, status history, and support reference.	Explain the public state and escalate with ids, not source details.
Partial or rejected route	Compare requested quantity, filled quantity, limit/slippage rule, and terminal status.	Apply fallback, retry, or manual review policy from the owning product.
Settlement record missing	Join execution report to settlement/reconciliation references and check the owning product closeout.	Keep finance state open until closeout evidence exists.

The runbook should be available before launch. A 0Link-enabled workflow is not complete if only engineering can explain why a route was available, unavailable, confirmed, partial, rejected, or reconciled.

API boundary

0Link endpoint-level access is not the default public integration path. For most public integrations, use 0Gate or 0Pools. If 0Bit enables a 0Link path for your account, treat your account contract and product documentation as the implementation authority until public API pages are released.

Developer checklist

Keep 0Link behind the owning product workflow.
Store route ids, preview ids, confirmation ids, execution report ids, and support references.
Do not show source names, source depth, connector behavior, or private route scoring to customers.
Separate indicative preview from confirmed/executable route terms.
Handle unavailable, partial, rejected, cancelled, and stale route states explicitly.
Join execution reports to settlement or reconciliation records before finance closeout.