> ## Documentation Index > Fetch the complete documentation index at: https://docs.joinluminous.com/llms.txt > Use this file to discover all available pages before exploring further. # Allocate a sales order onto a purchase order > Peg one or more sales-order lines onto an existing **active** purchase order so they auto-fulfil when the purchase order is received (the "add-to-existing-PO" step of the Purchase-to-Order / container workflow). The allocation appends the required line to the purchase order and creates a peg from the sales-order line to it; on receipt the peg is released and an auto-generated fulfillment order ships the pegged quantity. For each line, `fulfillment_channel_id` is optional — when omitted the service resolves the channel from the line's routing suggestion and **strict-fails with `422`** if routing is ambiguous, rather than risk mis-pinning the fulfillment order. In that case, retry with an explicit `fulfillment_channel_id`. Only active purchase orders accept new allocations; a `409 Conflict` is returned otherwise. > **Note:** This endpoint is gated by the `PURCHASE_TO_ORDER` feature flag. Contact Luminous to > have it enabled for your tenant. ## OpenAPI ````yaml /api-reference/build.yaml post /purchase-orders/{purchaseOrderId}/allocate openapi: 3.0.0 info: title: Luminous API version: 1.0.0 description: API documentation for Luminous servers: - url: https://{companyName}.api.joinluminous.com/external/api/v1 variables: companyName: default: companyName description: Your company-specific subdomain security: [] tags: - name: Products description: Get and manage products - name: Pricing description: Manage price schedules, levels, and customizations - name: BOMs description: Manage Bills of Materials (BOMs) - name: Labels description: Label rendering via Labelary ZPL service - name: Companies description: Manage business accounts and their associated data - name: Contacts description: Manage contact information for individuals - name: Suppliers description: Manage suppliers (factories) — vendors used on purchase orders - name: Supplier SKUs description: Manage per-supplier SKU and unit-cost overrides for products - name: Locations description: Manage warehouses and locations - name: Inventory description: Get and adjust product stock levels - name: Lots description: Create, update, and delete product lots (batches) - name: Transfer Orders description: Manage transfer orders - name: Fulfillment Orders description: Manage fulfillment orders and picklists - name: Fulfillment Priority Lists description: Configure fulfillment routing priority lists - name: Purchase Orders description: Get and modify purchase orders - name: Supplier Portal description: >- Read a supplier's response to a purchase order and control the one-click portal link - name: Receiving Reports description: Manage receiving reports - name: Payment Obligations description: Manage payment obligations for purchase orders - name: Sales Orders description: Manage sales orders and sales order shipments - name: Purgatory description: >- Inspect and resolve non-posted sales orders in the purgatory staging workflow - name: PickFlow Shipping description: >- Provider-agnostic shipping rates, services, packages, and label purchase for PickFlow - name: Cycle Counts description: >- Create, drive, and post PickFlow cycle counts — batches, per-warehouse sessions, and CSV import/export - name: Print Stations description: List paired print stations and enqueue print jobs to them - name: Invoices description: Get and manage invoices - name: Work Orders description: >- Manage work orders — production lifecycle, steps, materials, links, shipments, and comments - name: Production Batches description: Group and manage work orders as production batches - name: Bills description: >- Accounts payable bill management, payments, attachments, allocations, and variance - name: Prepayments description: Manage vendor prepayments and applications - name: Vendor Credits description: Manage vendor credits and applications - name: Vendor Returns description: Manage vendor returns and credit generation - name: Customer Returns description: Manage customer returns (sales returns), receiving, and restock behavior - name: Stock Snapshot description: Point-in-time stock snapshots with export support - name: Consumption description: Consumption reports and exports - name: Inventory Aging description: Cost-layer-based inventory aging reports - name: Bills Reports description: Accounts payable bills aging reports - name: Forecast description: Materialized forecast data - name: Reports description: Close the books, inventory discrepancy, transaction COGS, and EDI reports - name: Tags description: Add/remove tags across various resources - name: Custom Fields description: Get and set custom fields across various resources - name: Currency description: Currency configuration, exchange rates, and conversion - name: Integration Mappings description: Manage integration mappings for external systems - name: Integration Field Mappings description: Manage field-level mappings between Luminous and external systems paths: /purchase-orders/{purchaseOrderId}/allocate: post: tags: - Purchase Orders summary: Allocate a sales order onto a purchase order description: > Peg one or more sales-order lines onto an existing **active** purchase order so they auto-fulfil when the purchase order is received (the "add-to-existing-PO" step of the Purchase-to-Order / container workflow). The allocation appends the required line to the purchase order and creates a peg from the sales-order line to it; on receipt the peg is released and an auto-generated fulfillment order ships the pegged quantity. For each line, `fulfillment_channel_id` is optional — when omitted the service resolves the channel from the line's routing suggestion and **strict-fails with `422`** if routing is ambiguous, rather than risk mis-pinning the fulfillment order. In that case, retry with an explicit `fulfillment_channel_id`. Only active purchase orders accept new allocations; a `409 Conflict` is returned otherwise. > **Note:** This endpoint is gated by the `PURCHASE_TO_ORDER` feature flag. Contact Luminous to > have it enabled for your tenant. operationId: allocatePurchaseOrder parameters: - in: path name: purchaseOrderId required: true schema: type: integer description: ID of the purchase order to allocate onto requestBody: required: true content: application/json: schema: type: object required: - sales_order_id - lines properties: sales_order_id: type: integer description: ID of the sales order whose lines are being allocated example: 5001 ship_complete: type: boolean description: > When `true`, attempt to release the whole sales order as a single ship-complete fulfillment once every held line is coverable. Omit to leave the order's existing ship-complete behavior unchanged. example: false lines: type: array minItems: 1 description: Sales-order lines to peg onto this purchase order items: type: object required: - sales_order_item_id - quantity properties: sales_order_item_id: type: integer description: >- ID of the sales-order line item (must belong to `sales_order_id`) example: 78001 quantity: type: number format: float minimum: 0.001 description: >- Quantity to allocate from this line onto the purchase order example: 10 fulfillment_channel_id: type: integer nullable: true description: > Fulfillment channel to pin the auto-generated fulfillment order to. Optional — resolved from the line's routing suggestion when omitted (strict-fails with `422` if routing is ambiguous). example: 42 sales_item_id: type: integer nullable: true description: > Component ("sales item") the allocation targets. A kit sales-order line explodes into one row per component and a purchase-order line covers a single SKU, so a kit allocation must name the specific component being pegged. Omit for simple (non-kit) lines, where the sales-order line item alone identifies the SKU. example: 91001 split_mode: type: string enum: - atomic - component default: atomic description: > How a kit's components are sourced across warehouses. `atomic` (default) ships a kit's components assembled from a single warehouse; `component` allows a per-component cross-warehouse split. Component-level splitting is a future phase and is currently rejected for kits by the service. example: atomic examples: allocate_line: summary: Allocate a single sales-order line value: sales_order_id: 5001 lines: - sales_order_item_id: 78001 quantity: 10 responses: '200': description: Sales order lines allocated content: application/json: schema: type: object properties: data: type: object properties: pegsCreated: type: integer description: Number of allocation pegs created example: 1 purchaseOrderIds: type: array description: IDs of the purchase orders touched by the allocation items: type: integer example: - 9001 fulfillmentOrderIds: type: array description: >- IDs of any fulfillment orders generated by the allocation items: type: integer example: [] '401': description: Unauthorized content: application/json: schema: type: object properties: message: type: string '404': description: Purchase order or sales order not found content: application/json: schema: type: object properties: message: type: string '409': description: >- Conflict - the purchase order is not active and cannot take new allocations content: application/json: schema: type: object properties: message: type: string '422': description: > Unprocessable entity - validation error, a line item that does not belong to the sales order, or an unresolvable fulfillment channel. content: application/json: schema: type: object properties: message: type: string security: - BearerAuth: [] components: securitySchemes: BearerAuth: type: http scheme: bearer description: >- Authenticate using a bearer token. To create a token, navigate to /settings/api-tokens and click Create API Token. ````