OrdersService class (accessed via client.orders) manages the entire commerce lifecycle. All order write operations require mandatory HMAC Security to ensure complete data integrity.
Sandbox isolation: Orders created with a
tybrite_sk_test_* key are stored in the sandbox environment and are never visible to production keys, and vice versa. Every response includes a Tybrite-Environment: sandbox | production header confirming which environment your key resolved to.🔐 Security & Signing (HMAC)
To prevent tampering, replay attacks, and duplicate processing of updates,createOrder and updateOrder require both an HMAC-SHA256 signature and a mandatory Idempotency Key.
Signing Process
- Generate Timestamp: Get the current Unix timestamp in seconds.
- Prepare Payload: Concatenate the timestamp and the JSON request body with a dot:
timestamp + "." + JSON_body. - Generate Signature: Compute an HMAC-SHA256 signature of the payload using your HMAC Secret (found in Integrations → Developer).
- Base64 Encode: The resulting signature must be Base64 encoded.
Code Implementation (TypeScript/Node.js)
Core Operations
listOrders
Retrieve a paginated list of your store’s orders, newest first. Use this to build order dashboards, fulfillment queues, or customer order history — anywhere you need to browse orders without already knowing an order ID.
The list returns order summaries without line items (to keep responses fast). When you need the full order including its items, call getOrder with the order’s id.
Parameters (all optional):
has_more is false:
reserveStock
Optional. Holds stock for the items a customer is checking out so they can’t be sold to someone else while payment is in flight. Returns 201 with reservation_ids and an expiry.
Use it when there’s a gap between “customer commits to buy” and “payment confirms” — card redirects, 3-D Secure, mobile-money prompts — so the stock is claimed before the customer pays. For instant-capture or synchronous flows you can skip it and call createOrder directly; Galactic Core still prevents stock from going negative at order time. Reserving is a stronger guarantee for async payments, not a mandatory step before every order.
Reservations are all-or-nothing: if any item lacks available stock, nothing is reserved and you get 409 insufficient_stock. Each hold expires automatically (15 minutes by default); an abandoned checkout simply lets the hold lapse — no explicit release needed. Works with publishable or secret keys.
reserveStock call itself returns:
Response
createOrder
Place a new order. Returns 201 Created (semantic create) with the new order resource. Requires verified signatures and idempotency protection.
- Required body fields:
customer_email,customer_name,billing_address,shipping_address,subtotal,total_amount,payment_method, and a non-emptyitemsarray. Each item must includevariant_idorproduct_id(at least one). variant_idvsproduct_idper item — prefervariant_id(the exact variant the shopper chose; pass the same one you put in the cart straight through). If you send onlyproduct_id, the order is placed against the product’s default variant — fine for single-variant products, but for a multi-variant product it may not be the one the shopper selected. Sending both is fine:variant_idwins andproduct_idis resolved from it. See Products and variants — which ID to send where for the full picture.- Optional:
customer_id(guest checkout is supported — pass customer details without acustomer_id),customer_phone,product_nameper item (resolved from the product if omitted),tax_amount,shipping_amount,discount_amount,notes,gift_card_redemption,promotion_usages, andreservation_ids(fromreserveStock— converts a checkout hold into the stock deduction instead of a fresh decrement). - Tax: if you omit
tax_amountand the store has automatic tax enabled, Galactic Core calculates jurisdiction-accurate tax for theshipping_addressand returns it on the order astax_amount, with a per-jurisdictiontax_breakdownarray and atax_sourceofautomatic. If automatic calculation is unavailable it falls back to the store’s configured rate (tax_source: fallback) so the order never fails on tax. If you pass your owntax_amount(e.g. you calculated tax elsewhere), it is honored as-is. See Order schema for the fields. - Shipping:
shipping_amountis validated server-side (like prices and tax) so a tampered value is rejected. For a zone/distance store, passshipping_latitude+shipping_longitudeand the amount is checked against the resolved delivery fee. For a multi-carrier (Shippo) store, pass the chosenshippo_rate_id(from acalculateShippingquote’srates[]) and the amount must match that real carrier quote. A mismatch returns400 price_mismatch. (When shipping can’t be resolved server-side, the value is accepted and marked unverified — a sale never fails on shipping.) - Store credit: pass
apply_store_credit: true(optionally withstore_credit_amountto cap it) to spend the customer’s redeemable store-credit balance against this order. Requires acustomer_id. The amount actually applied — capped at the order total and the available balance — is returned asstore_credit_applied. - Ad conversion tracking (optional): if the shopper arrived from a paid ad, pass the click id —
gclid(Google) and/orfbclid(Meta / Facebook & Instagram) — and their privacy-consent state asad_consent: { ad_user_data, ad_personalization, jurisdiction }(each consent value'granted' | 'denied' | 'unspecified';jurisdictionis the shopper’s region, e.g.EEA/UK/CH/US). On a paid order this lets the merchant’s advertising get credit for the sale on each platform. Galactic Core records the consent state with the order and only reports the conversion to the ad platform where the shopper’s consent and region allow it — so always forward the true captured values (never guess). The Meta conversion is sent server-side and de-duplicated against the storefront’s Meta Pixel using the order id, so it counts even when the browser blocks the Pixel. Storefront generators should wire this alongside a consent banner for EEA, UK, and Swiss visitors. - Missing a required field returns
400with a message naming the field. - Replay Protection: The
X-Timestampmust be within 5 minutes of the server time. - Post-processing: When
payment_status: "paid"is set, Galactic Core applies gift card redemption, stock reduction, and customer metrics updates. See Post-Processing Warnings below — the response may include apost_processing_warningsarray that you must check.
Response
createOrder returns { order, store_credit_applied?, post_processing_warnings? }. store_credit_applied is present only when store credit was applied. getOrder, updateOrder, and listOrders return the order resource(s) at the top level.Post-Processing Warnings
When an order is created withpayment_status: "paid", Galactic Core applies these follow-up steps:
- Gift card redemption (if
gift_card_redemptionprovided) - Stock reduction per item
- Customer metrics update (purchase count and lifetime value)
post_processing_warnings array. You MUST check this array and route any failures to a support or retry flow.
Response shape
Handling pattern
Customer metrics (
total_purchases, lifetime value) update automatically when an order is paid. Counts stay accurate even when many orders for the same customer are placed at once — no action needed on your side.getOrder
Retrieve complete details for a specific order.
Response
updateOrder
Update fulfillment or payment status. Requires HMAC signature and Idempotency Key.
- Idempotency: Use a unique key for each distinct update (e.g.,
update-payment-{order_id}-{timestamp}). - Protection: This prevents double-triggering side effects like accounting entries or inventory reduction on network retries — and lets the SDK auto-retry the call safely.
Response
Security & Error Handling
Side Effects of payment_status: 'paid'
Transitioning an order to the paid state automatically triggers:
- Inventory Sync: Live stock reduction across variants.
- Accounting Engine: Double-entry bookkeeping entry creation.
- LTV Update: Increments customer lifetime value and purchase counts (accurate even under heavy concurrent order load).
- Promoter Logic: Marks loyalty points and promotion usage as finalized.

