Read the real inventory context
Items, locations, bins, counts, suppliers, POs, reservations, and receiving events need stable API access before agents can draft useful work.
Developer proof
Inventory API for items, locations, POs, approvals, and audit history.
The Order3 API is the technical path for teams that need inventory records, purchasing drafts, approvals, and activity history available to internal systems and agent workflows.
Current state
Public API documentation is being finalized. Evaluation teams can review the current API shape during an Inventory Workflow Review.
Capabilities
API keeps the same inventory controls as the product.
Technical access is useful only when it preserves the same records, approval paths, and activity history that operators rely on.
Draft before changing records
Reorder, transfer, and adjustment work starts as a draft with rationale, affected records, and an approval owner.
Write through permissions
Tokens and workspace roles limit which systems can read, draft, approve, execute, export, or change records.
Keep an activity trail
Every agent action, API write, approval, dismissal, and sync creates an event the team can inspect later.
Agent workflow
Observe, detect, explain, draft, approve, execute, audit.
The technical surface keeps the agent path inspectable. A human or policy owner stays attached to expensive or risky actions.
01
Observe records
Read item, location, supplier, PO, count, reservation, and receiving context from the same model the web and mobile apps use.
02
Detect exception
Find low stock, count drift, short receiving, supplier delay, or a channel/accounting mismatch that needs a next action.
03
Explain the evidence
Return the SKU, location, supplier, open PO, count history, owner, timestamp, and reason the exception exists.
04
Draft action
Create a PO draft, transfer request, count task, supplier note, or reconciliation step with the reason attached.
05
Approve
Route the draft to a human or policy owner before spend, supplier messages, or inventory value changes.
06
Execute
Approved work writes through normal inventory flows instead of bypassing the product's controls.
07
Audit
Record the request, approval, execution result, affected records, and actor in activity history.
Guardrails
The technical path makes unsafe shortcuts hard.
Inventory agents are only useful if teams can see what happened, who approved it, and which records changed.
No blind writes
Important record changes and spend requests require explicit permission scope, idempotency, and an approval rule.
No hidden overwrite
If a sync sees conflicting item, location, supplier, or PO data, it produces an exception instead of silently picking a winner.
No missing owner
Every draft, approval, dismissal, and system write has a user, agent, token, or integration owner attached.
Purpose
What the API is for
The API is for teams building custom inventory, purchasing, finance, channel, supplier, or agent workflows around Order3. The useful objects are operational: items, locations, bins, counts, movements, suppliers, POs, receiving events, approval drafts, and activity events. The API exposes the same records the team sees in the product, not a separate integration-only model.
Agent role
How agents use it
An agent reads inventory context, explains the exception, prepares a draft, routes approval, and records the result. It does not silently change stock, send supplier spend, or rewrite history. The useful pattern is narrow: software prepares the work; people stay in control of spend and inventory value.
Order3 API questions
Is the Order3 API public today?
Public documentation is being finalized. If API access is part of your evaluation, bring the workflow to an Inventory Workflow Review and we will show the current shape and the gaps directly.
Which records does the API cover?
The target surface is items, locations, counts, movements, suppliers, POs, receiving, approvals, activity history, and integration events. Exact availability depends on the rollout path.
Can an API client approve or execute work?
Only through permissioned flows. The design keeps approval, policy, and activity history attached to the action so an integration cannot bypass the controls a human user would see.
Technical evaluation
Bring the technical workflow and the control boundary.
We will map the records, API or agent surface, approval points, execution rules, and activity history before the workflow runs under policy.