Integration

Stord
automation.

3 automated actions available through Cerebral OS. Connect Stord to any workflow, Cerebral, or Map — with full governance, audit trail, and dry-run safety on every execution.

3 actions · · governed execution

Execution trace
live
3
actions
100%
governed
<200ms
latency
3
Automated actions
1
Read operations
2
Write operations
2,800+
Compatible Maps
Actions

What you can do
with Stord.

Every action below is available as a verb in Cerebral OS — callable from a Cerebral, a Map, or the Runtime API. All executions are governed, audited, and dry-run safe.

cancel order
stord:cancel_order
WORKFLOW: 1. Check order is cancellable (use stord:get_sales_order first) 2. Send cancellation request to Stord 3. Order moves to cancelled status CRITICAL REQUIREMENTS: - MUST check order status first with stord:get_sales_order - Only cancel if status: "open" and shipped_at: null - If order already shipped, cancellation will fail - This is PERMANENT - cannot undo USE CASES: - Address change: Cancel + recreate with new address - Customer cancellation request - Wrong order created (need to recreate) DANGER: - If recreate fails after cancel, order is lost - Always have new order details ready BEFORE cancelling - Consider manual escalation instead for safety
Write Low risk
create sales order
stord:create_sales_order
WORKFLOW: 1. Get original order details (stord:get_sales_order) 2. Cancel original order (stord:cancel_order) 3. Create new order with corrected details CRITICAL REQUIREMENTS: - Stord may auto-generate NEW order_number (CS number) - Must provide ALL order lines (SKUs, quantities) - Must provide complete ship_to_customer address - Channel ID should match original order CANCEL + RECREATE PATTERN: 1. stord:get_sales_order - Get full details 2. stord:cancel_order - Cancel old order 3. stord:create_sales_order - Create with new address RISKS: - If create fails after cancel, order is lost - New order gets NEW CS number (tracking changes) - Inventory might not be available when recreating FIELD MAPPING FROM GET RESPONSE: - custom_reference → custom_reference (PH number) - channel → channel_id - priority → priority (1-4) - customer → ship_to_customer.name - destination_address → ship_to_customer.address - sales_order_lines → order_lines
Write Low risk
get sales order
stord:get_sales_order
WORKFLOW: 1. Search for order by order_number 2. Return order status, shipped_at, destination_address, order_id 3. Use to determine if order can be modified: - status: "open" && shipped_at: null → Can still modify (cancel/recreate) - shipped_at: not null → Already shipped, too late - status: other → Check what it means CRITICAL USAGE: - Stord has NO update API - can only cancel + recreate - This verb checks if cancel+recreate is possible - If status: "open", order can be cancelled and recreated with new address - If shipped_at exists, too late - order already in transit STORD UI URL: Construct URL: https://shipper.stord.com/distribution_networks/{network_id}/orders/sales/{order_number} This allows escalation to human to manually update in Stord UI
Read Low risk
How it works

Every Stord action
governed end-to-end.

Cerebral OS isn't a connector. It's the execution layer that sits in front of Stord — adding governance, dry-run safety, and a full audit trail to every operation.

Governance first
Every verb carries a risk classification. High-risk writes require explicit approval gates before they execute in production.
Dry-run safe
Simulate any Stord action before it touches production. See exactly what would happen before a single real call is made.
Immutable audit trail
Every Stord action is logged — what ran, what changed, who approved it, when it happened. Full history on every verb, forever.
Stord integration

3 actions.
Governed by default.

Connect Stord to any workflow in minutes. Dry-run every action before it touches production. Full audit trail on everything.

Connect Stord free Browse all integrations →