> ## Documentation Index > Fetch the complete documentation index at: https://docs-pos.solya.app/llms.txt > Use this file to discover all available pages before exploring further. # Read the order-routing rules > Returns the network's order-routing policy: the `criteria` that rank candidate stores, in PRIORITY ORDER. They are successive tie-breakers, not filters — the first criterion that separates two stores decides, and the next is consulted only on a tie. A store that no criterion distinguishes is settled by the final, always-applied tie-break: the lowest `storeId`. That makes routing reproducible — the same order routed twice always picks the same store. The criteria, and the ONLY ones that exist: `stock-depth` (with `direction`: `deepest` — spend the stock the network can most afford to spend — or `shallowest` — drain small positions); `store-priority` (with `storeIds`, best first); and `region-priority` (with `regions`, best first, matched on the store's `region`). There is deliberately NO proximity/distance criterion: an order carries no address and a store carries no coordinates, so distance is not computable from anything in this system. Do not attempt to approximate it with `region-priority` — that is a STATIC merchant preference for certain regions, not a distance to the customer. Takes no parameters and always answers 200: before anything has been saved it returns the DEFAULT policy (a single `stock-depth`/`deepest` criterion), which is the ranking the network is genuinely routing under, not a placeholder. So an unconfigured network and a network that explicitly chose stock depth are reported identically, because they behave identically. ALWAYS call this before the update operation: the update replaces the document wholesale. ## OpenAPI ````yaml /openapi.json get /v1/routing-rules openapi: 3.0.3 info: title: Solya POS API version: 1.0.0 description: >- The Solya POS backend HTTP surface. Every documented operation is agent-ready: it carries an `operationId`, an agent-facing `description`, the `pos.*` scopes it enforces (`x-required-permissions`) and an `x-agent-tier`. Success responses return the payload as raw JSON; failures return the `ErrorResponse` envelope (`{ error: { code, message, statusCode } }`). servers: - url: / description: The backend, relative to its deployed origin. security: [] paths: /v1/routing-rules: get: tags: - Settings summary: Read the order-routing rules description: >- Returns the network's order-routing policy: the `criteria` that rank candidate stores, in PRIORITY ORDER. They are successive tie-breakers, not filters — the first criterion that separates two stores decides, and the next is consulted only on a tie. A store that no criterion distinguishes is settled by the final, always-applied tie-break: the lowest `storeId`. That makes routing reproducible — the same order routed twice always picks the same store. The criteria, and the ONLY ones that exist: `stock-depth` (with `direction`: `deepest` — spend the stock the network can most afford to spend — or `shallowest` — drain small positions); `store-priority` (with `storeIds`, best first); and `region-priority` (with `regions`, best first, matched on the store's `region`). There is deliberately NO proximity/distance criterion: an order carries no address and a store carries no coordinates, so distance is not computable from anything in this system. Do not attempt to approximate it with `region-priority` — that is a STATIC merchant preference for certain regions, not a distance to the customer. Takes no parameters and always answers 200: before anything has been saved it returns the DEFAULT policy (a single `stock-depth`/`deepest` criterion), which is the ranking the network is genuinely routing under, not a placeholder. So an unconfigured network and a network that explicitly chose stock depth are reported identically, because they behave identically. ALWAYS call this before the update operation: the update replaces the document wholesale. operationId: getRoutingRules responses: '200': description: The current routing policy (the stock-depth default if never saved). content: application/json: schema: type: object properties: criteria: type: array items: oneOf: - type: object properties: kind: type: string enum: - stock-depth direction: type: string enum: - deepest - shallowest required: - kind - direction additionalProperties: false - type: object properties: kind: type: string enum: - store-priority storeIds: maxItems: 500 type: array items: type: string minLength: 1 required: - kind - storeIds additionalProperties: false - type: object properties: kind: type: string enum: - region-priority regions: maxItems: 500 type: array items: type: string minLength: 1 required: - kind - regions additionalProperties: false required: - criteria additionalProperties: false description: >- The current routing policy (the stock-depth default if never saved). example: criteria: - kind: stock-depth direction: deepest '400': description: >- The request failed schema validation; `error.fieldErrors` lists the fields. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: No valid credential was presented — send a bearer token. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: The actor is authenticated but lacks the required `pos.*` scope. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': description: An unexpected server error — safe to retry idempotent requests. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] components: schemas: ValidationErrorResponse: type: object required: - error additionalProperties: false description: >- A `VALIDATION_FAILED` envelope carrying the offending fields in `fieldErrors`. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED message: type: string statusCode: type: integer fieldErrors: type: array description: >- One entry per rejected field: the field path and why it was rejected. items: type: object required: - field - message additionalProperties: false properties: field: type: string description: Dot-path of the offending field. message: type: string description: Why the field was rejected. ErrorResponse: type: object required: - error additionalProperties: false description: The uniform failure envelope every non-2xx response returns. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED - UNAUTHORIZED - FORBIDDEN - NOT_FOUND - CONFLICT - BUSINESS_RULE_VIOLATION - INTERNAL_ERROR description: >- Machine-readable kernel `ResultCode` — branch on this, not on `message`. message: type: string description: >- Human-readable explanation. Safe to surface; never leaks server internals. statusCode: type: integer description: >- The HTTP status, mirrored into the body so a client need not read headers. securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- `Authorization: Bearer `. Accepts EITHER a Keycloak access token (scopes-in-token) OR an opaque POS session token; both resolve to the same `pos.*` scope vocabulary the route guards enforce. ````