Skip to main content
The 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

  1. Generate Timestamp: Get the current Unix timestamp in seconds.
  2. Prepare Payload: Concatenate the timestamp and the JSON request body with a dot: timestamp + "." + JSON_body.
  3. Generate Signature: Compute an HMAC-SHA256 signature of the payload using your HMAC Secret (found in Integrations → Developer).
  4. Base64 Encode: The resulting signature must be Base64 encoded.

Code Implementation (TypeScript/Node.js)

NEVER expose your HMAC Secret client-side. Signing should always occur on a secure backend server. Requests with missing or invalid signatures will return 401 Unauthorized.

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.
Reading orders requires a Secret Key. Publishable keys receive 403 Forbidden. Order data contains customer details, addresses, and payment status — it must never be exposed to browsers.
Parameters (all optional):
Paging through all results — keep calling with the returned cursor until has_more is false:
Response shape:

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.
The 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-empty items array. Each item must include variant_id or product_id (at least one).
  • variant_id vs product_id per item — prefer variant_id (the exact variant the shopper chose; pass the same one you put in the cart straight through). If you send only product_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_id wins and product_id is 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 a customer_id), customer_phone, product_name per item (resolved from the product if omitted), tax_amount, shipping_amount, discount_amount, notes, gift_card_redemption, promotion_usages, and reservation_ids (from reserveStock — converts a checkout hold into the stock deduction instead of a fresh decrement).
  • Tax: if you omit tax_amount and the store has automatic tax enabled, Galactic Core calculates jurisdiction-accurate tax for the shipping_address and returns it on the order as tax_amount, with a per-jurisdiction tax_breakdown array and a tax_source of automatic. 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 own tax_amount (e.g. you calculated tax elsewhere), it is honored as-is. See Order schema for the fields.
  • Shipping: shipping_amount is validated server-side (like prices and tax) so a tampered value is rejected. For a zone/distance store, pass shipping_latitude + shipping_longitude and the amount is checked against the resolved delivery fee. For a multi-carrier (Shippo) store, pass the chosen shippo_rate_id (from a calculateShipping quote’s rates[]) and the amount must match that real carrier quote. A mismatch returns 400 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 with store_credit_amount to cap it) to spend the customer’s redeemable store-credit balance against this order. Requires a customer_id. The amount actually applied — capped at the order total and the available balance — is returned as store_credit_applied.
  • Ad conversion tracking (optional): if the shopper arrived from a paid ad, pass the click id — gclid (Google) and/or fbclid (Meta / Facebook & Instagram) — and their privacy-consent state as ad_consent: { ad_user_data, ad_personalization, jurisdiction } (each consent value 'granted' | 'denied' | 'unspecified'; jurisdiction is 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 400 with a message naming the field.
  • Replay Protection: The X-Timestamp must 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 a post_processing_warnings array that you must check.
Response
Because you pass an idempotencyKey, the SDK can safely auto-retry this call on a transient failure — a retry returns the original order rather than creating a duplicate.
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 with payment_status: "paid", Galactic Core applies these follow-up steps:
  1. Gift card redemption (if gift_card_redemption provided)
  2. Stock reduction per item
  3. Customer metrics update (purchase count and lifetime value)
If any step fails, the order is still recorded — but the response includes a 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.
Reading orders requires a Secret Key. Publishable keys receive 403 Forbidden. Order data contains customer PII, addresses, and payment status — it must not be exposed to browsers.
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.
The full updated order is returned at the top level:
Response

Security & Error Handling

Side Effects of payment_status: 'paid'

Transitioning an order to the paid state automatically triggers:
  1. Inventory Sync: Live stock reduction across variants.
  2. Accounting Engine: Double-entry bookkeeping entry creation.
  3. LTV Update: Increments customer lifetime value and purchase counts (accurate even under heavy concurrent order load).
  4. Promoter Logic: Marks loyalty points and promotion usage as finalized.

Response Codes