craft
Queue a crafting job (auto-routes to your own/faction facility, or hand-crafts at the Station Workshop) (Must be docked. Ordinary recipes require crafting and storage service; package recipes use the rules described below. Crafting is no longer instant: it queues a job that runs over subsequent ticks (check progress by calling craft with no recipe_id). You do NOT need to poll: each tick a job deposits finished output you get a 'crafting_update' notification (category 'crafting' in get_notifications) naming exactly what was made and where, with runs_remaining and a completed flag — so re-issuing the same craft because 'nothing happened yet' only stacks a duplicate job. 'quantity' is the number of OUTPUT ITEMS you want, rounded up to a whole number of production runs (a recipe that yields several items per run may make a few extra). Materials are escrowed from your station storage at enqueue (NOT cargo) and outputs are delivered to station storage on completion — deposit your inputs to storage first. Auto-routing prefers your OWN facility, then your FACTION's, then one an ALLIED faction has granted you access to (free to you, but queued at external priority), then a public rental, and only hand-crafts at the Station Workshop (speed scales with crafting/refining skill) when none is available — pass preset "workshop" to force hand-crafting, or facility_id to target one, plus optional preset "fast" (soonest finish globally, so a busy own facility may route to an idle public rental), "cheap" (lowest fee you would actually pay — your own and your faction's facilities are free to you, so they always win), or "prefer_own" (keep the job on your own/faction/ally-granted facility, renting a public one only when you have none that can run it). The Station Workshop is hand-crafting (your own labor, not the station's facility): its jobs advance only while you stay docked at that base and pause if you undock, resuming when you return — whereas a job at a real production facility you own or rent keeps running while you're away. deliver_to=faction crafts from/to faction storage (needs manage treasury permission), and deliver_to=faction: pulls inputs from and deposits outputs into a specific faction Storage Extension bucket; and if you leave deliver_to off and your own storage/credits can't cover the job, it automatically draws from your faction's storage/treasury when you're allowed to spend them. Renting another player's public facility prepays a per-run fee. COST CHECK: add dry_run=true to get a quote — the materials, labor, and rental fee the job would cost, the venue it auto-routes to, whether you can afford it, and the ETA — without queuing or spending anything (not supported with bulk jobs). Use 'recycle' to reverse a recipe at a recycler. BULK: pass jobs=[{recipe_id, quantity, facility_id?, preset?, deliver_to?, source?, package_ids?, output_package_label?}, ...] to queue many crafts in one action (up to 50 facilities at once instead of one job per tick) — each entry is queued independently and the response reports per-job success/failure. Each entry accepts the same package_ids (source inputs from packages) and output_package_label (seal outputs into a new package) fields as a single craft. QUEUE & CANCEL: call craft with no recipe_id to list your queued jobs, their IDs, and each job's current deliver_to — that is the portable form and it works on every transport. (The legacy WebSocket v1 payload also accepts an explicit "action":"queue" field, but the v2 REST/MCP/WebSocket transports reserve "action" for routing and strip it from the request body — which is why it is absent from the v2 request schema — so a v2 request that sets it alongside a recipe_id queues a craft instead of listing.) Pass job_id= to cancel a queued job and refund its unconsumed inputs, labor, and fees (the same operation as facility action=job_cancel). Pass job_ids=[id1,id2,...] to cancel several at once (per-job success/failure). RETARGET: pass job_id= together with deliver_to=<storage|faction|faction:bucket> to redirect a queued or running job's REMAINING output to a different store at the same station without cancelling it — the recipe, quantity, source, escrow, cost, venue, ETA, and queue position are all unchanged, and runs already delivered stay where they landed. Only the job's own orderer may retarget it (a facility owner may cancel a rental order but not redirect its output), the new destination is permission-checked exactly as it is at queue time, and pack_package/unpack_package jobs cannot be retargeted. PACKAGE INPUTS/OUTPUT: package_ids=[...] sources the craft's inputs from those packages (raw id or package:) instead of loose storage — they must all sit in the source location and their pooled contents must equal the recipe inputs times quantity EXACTLY (no shortage or overage, no storage backfill), or it's rejected before anything is consumed. output_package_label="..." holds the outputs and, on completion, seals the whole job's output into one new package with that label in the destination, consuming one cargo_container; cancelling instead refunds the inputs with no package. The package id is pre-generated: both the queue response and the completion crafting_update return output_package_id, so you never need to poll storage to find the sealed package. Both need an accessible Logistics facility (your own, your faction's, a public rental, or a station-owned one), and with output_package_label the total output must fit one package (size <= 100). Add dry_run=true to preview a packaged craft — it reports the exact inputs and cost, the output package it would seal, and whether every gate (exact match, Logistics, a container, single-package size, destination room) would pass, without consuming anything. Not supported with bulk jobs. PACKAGE RECIPES: recipe_id=pack_package takes items, label, source, and target; it consumes one cargo_container, packs at most 100 total item size, and requires Logistics. recipe_id=unpack_package takes package_id, source, and target; A Logistics facility is fast, returns the container, and uses that facility's normal access/rental rules without requiring the station's generic crafting service. preset="workshop" is much slower, consumes the container, and requires the station's crafting service. source/target accept storage, cargo, faction, or faction:; target defaults to source (deliver_to is an alias). Package jobs use this same queue and job_id cancellation.)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| jobs | No | Bulk mode: queue many crafts in one action. Each entry accepts the same input-sourcing and output-packaging fields as a single craft — package_ids to source inputs from packages, output_package_label to seal outputs into a new package — plus items, package_id, label, and target. Each job commits independently with partial success. Max 50. | |
| count | No | Alias for quantity (used when quantity is not set). | |
| items | No | For pack_package: selected items to pack; total unpacked size may not exceed 100. | |
| label | No | For pack_package: player-authored package label. | |
| action | No | Use action='queue' to list your current crafting jobs instead of queuing a new one, action='cancel' to cancel the job named by job_id (passing a bare job_id implies cancel too), or action='retarget' to send the job named by job_id somewhere else (job_id + deliver_to implies retarget too). | |
| job_id | No | Act on this queued job instead of crafting. Call craft with no recipe_id to list your job IDs. job_id alone cancels it (refunding its unconsumed inputs, labor, and rental fee); job_id together with deliver_to instead redirects the job's REMAINING output to that destination, keeping its recipe, runs, escrow, cost, and queue position. | |
| preset | No | Auto-routing preset: 'fast' (fewest ticks, default) picks the best facility globally, so a busy own facility may route to an idle public rental. 'cheap' picks the lowest fee you would actually pay — your own and your faction's facilities are free to you, so they always win. Use 'prefer_own' to keep the job on your own (then faction, then ally-granted) facility and only rent a public one when you have none that can run it. Auto-routing otherwise prefers your own facility, then your faction's, then one an allied faction has granted you access to (free to you, but queued at external priority), then a public rental, and only hand-crafts at the Station Workshop if none is available. Use 'workshop' to force hand-crafting even when you have a facility. | |
| source | No | Where inputs and labor/rental credits are pulled FROM. Same values as deliver_to: 'storage', 'faction', or 'faction:<bucket>'. Defaults to deliver_to, so inputs and outputs share one store unless you set them differently — e.g. source='storage' deliver_to='faction:Crafting' pulls from your personal storage and deposits into a faction bucket. | |
| target | No | For package recipes: output destination (storage, cargo, faction, or faction:<bucket>); defaults to source. deliver_to is accepted as an alias. | |
| dry_run | No | Return a cost+time quote (materials, labor, rental fee, auto-routed venue, ETA) without queuing or spending anything. Not supported with bulk jobs. | |
| job_ids | No | Bulk cancel: cancel many queued jobs in one action. Each ID is cancelled independently with per-job success/failure, so one bad ID doesn't sink the batch. Refunds the unconsumed escrow of every cancelled job. | |
| quantity | No | Number of output items to make (default 1). Rounded up to a whole number of production runs, so a recipe that yields several items per run may produce a few extra. | |
| recipe_id | No | Recipe ID to craft (use catalog with type=recipes to see available recipes). Inputs are escrowed from station storage at enqueue. | |
| deliver_to | No | Output destination: 'storage' (default), 'faction' (faction main store — requires manage treasury permission), or 'faction:<bucket name or id>' for a specific faction Storage Extension bucket. Pass it alongside job_id to redirect an ALREADY QUEUED job's remaining output there instead of queuing anything new. | |
| package_id | No | For unpack_package: package instance ID to unpack. | |
| session_id | Yes | Your session ID from login/register | |
| facility_id | No | Route to a specific facility ID (overrides auto-selection). | |
| package_ids | No | Source this craft's inputs from these packages (raw id or 'package:<id>' form) instead of loose storage items. The packages must all sit in the resolved source location, and their pooled contents must equal the recipe inputs (× quantity) EXACTLY — any shortage or overage is rejected before anything is consumed (no storage/cargo backfill). Their empty cargo_containers are reclaimed only when an accessible Logistics facility is present. | |
| output_package_label | No | Bundle the outputs into one package: instead of depositing outputs loose per run, the job holds them and seals them into a single new package with this label in the destination on completion, consuming one cargo_container. Requires an accessible Logistics facility, and the total output size across all runs must fit one package (<= 100). Cancelling refunds the inputs and produces no package. |