Create order
Create a new order with HMAC signature verification and idempotency protection.
π HMAC Signing (REQUIRED)
All order creation requests MUST include HMAC-SHA256 signature for security:
- Generate Timestamp: Get current Unix timestamp in seconds
- Create Payload: Concatenate
timestamp + "." + JSON_body - Sign Payload:
HMAC-SHA256(hmac_secret, payload)β base64 encode - Include Headers:
X-Timestamp: Unix timestamp (must be within 5 minutes)X-Signature: Base64-encoded HMAC signature
Example (Node.js):
π Idempotency Protection
Include Idempotency-Key header to prevent duplicate orders on retry.
If the same key is used, the original order is returned (not counted against rate limit).
β οΈ Security Notes:
- HMAC secret is displayed in the Integrations page (Developer section)
- Never expose HMAC secret in client-side code
- Regenerate secret immediately if compromised
- Requests with invalid/missing signatures return 401 Unauthorized
- Timestamps older than 5 minutes are rejected to prevent replay attacks
π‘οΈ Server-side price validation (anti-tampering)
HMAC proves the body wasnβt altered in transit; it does not prove the amounts are honest. So the server independently recomputes the order from authoritative data and rejects any mismatch β you cannot set your own prices or discounts:
- Item prices are recomputed from the live catalog.
unit_price/total_pricethat donβt match the catalog price β400 price_mismatch. (The stored order always uses the catalog price, never the value you send.) subtotal,tax_amount,total_amountmust reconcile tosubtotal + tax + shipping β discountover those catalog prices β otherwise400 price_mismatch.discount_amountis validated against the discount the promotions / gift card you claim actually grant (computed server-side frompromotion_usages+gift_card_redemption). Adiscount_amountgreater than that legitimate maximum β400 discount_invalid. A discount with no real promotion/gift card behind it β max is0. (You may apply less than the maximum.)shipping_amountmay not be negative β400 price_mismatch.
In short: send the real catalog prices and the actual promotions/gift card the shopper is entitled to. Donβt compute or invent prices/discounts client-side β the server is the authority.
Authorizations
API Key Authentication
Use your API key in the Authorization header:
Key Types:
Secret Keys (Server-Side Only):
- Format:
tybrite_sk_live_*(production) ortybrite_sk_test_*(sandbox) - Full read/write access to all endpoints
- β οΈ NEVER expose in client-side code or public repositories
- Required for: write operations, authentication, payment verification, AI recommendations
Publishable Keys (Client-Safe):
- Format:
tybrite_pk_live_*(production) ortybrite_pk_test_*(sandbox) - Read-only access (GET requests only, plus POST semantic search)
- β Safe for client-side JavaScript, mobile apps, and public code
- Allowed for: browsing products, search, CMS content, pricing queries
Endpoint-Specific Requirements:
- Authentication endpoints (
/v1/auth/*): Secret key required - Payment verification (
POST /v1/payments/verify): Secret key required - AI Recommendations (
POST /v1/recommendations): Secret key required - Semantic Search (
POST /v1/search): Both key types allowed (read-only operation) - All write operations: Secret key required
- All read operations: Both key types allowed
Using a publishable key for restricted operations returns 403 Forbidden.
Headers
Unique key to prevent duplicate orders (e.g., order-{timestamp}-{random})
Unix timestamp in seconds (current time). Must be within 5 minutes of server time. Used to prevent replay attacks.
HMAC-SHA256 signature of the payload (timestamp + "." + request_body), base64-encoded. Sign using your HMAC secret from the Integrations page (Developer section).
Body
Customer email address. Required.
"john.doe@example.com"
Customer full name. Required.
"John Doe"
Billing address. Required.
Shipping address. Required.
Order line items (at least one required)
1Provide variant_id OR product_id (at least one). Prefer variant_id β it is the exact variant (SKU) the shopper chose, so pass the same variant_id you put in the cart straight through to the order. If you send only product_id, the order is placed against the product's default variant β convenient for single-variant products, but for a product with multiple variants it may not be the one the shopper selected. When both are sent, variant_id wins (and product_id is resolved from it).
- Option 1
- Option 2
Payment method identifier (required)
card, stripe, paypal, paystack, mpesa, cash "card"
Subtotal before tax and shipping. Required.
2000
Total order amount (required)
2520
Customer UUID (optional - guest checkout supported)
"c320094c-eb65-4879-804c-83d2e1dd7f99"
Customer phone number (optional)
"+14155550199"
Payment status (defaults to pending)
pending, paid, failed, refunded "pending"
Order fulfillment status (defaults to pending)
pending, processing, shipped, delivered, cancelled "pending"
Tax amount
320
Shipping cost
200
Discount amount
0
Additional order notes
"Please deliver between 9 AM - 5 PM"
Shipping tracking number (optional, usually set on PATCH)
"1Z999AA10123456784"
Estimated delivery date and time (optional)
"2026-02-15T14:00:00Z"
External payment reference (e.g., Stripe charge ID, M-Pesa receipt)
"ch_1NqFvE2eZvKYlo2C8Z3y4abc"
Values for the merchant's own custom fields on this order, as
{ field_name: value }. Use this to carry a reference the merchant asked for at
checkout β a buyer's purchase-order number, a cost centre, a delivery instruction.
Each value is validated against the merchant's definition: a name that is not defined,
a value outside a select field's options, or a number that will not parse is
rejected. A rejected field does not fail the order β the order is created and
the reason is returned in post_processing_warnings, because the payment has already
been taken by that point. Read GET /v1/products/{id}/custom-fields or the order
response's custom_fields to discover which fields a merchant has defined.
Shipping calculation details from /v1/shipping/calculate for audit trail
Optional gift card to redeem towards this order
Promotion usages applied to this order (tracked when payment_status is paid)
Apply the customer's redeemable store credit to this order. When
true (and the order has a customer_id), store credit is spent
against the order total, capped at the total. The amount actually
applied is returned as store_credit_applied. Requires a customer.
true
Optional cap on how much store credit to apply. When omitted (and
apply_store_credit is true) up to the full order total is applied.
The applied amount never exceeds the available balance or the total.
25
Your own order reference. When omitted, Galactic Core generates one. Use this to keep order numbers aligned with a system you already run.
"ORD-10432"
ISO 4217 currency code the order is priced in. When omitted, the store's default storefront currency is used. Set it when you present prices in a currency the shopper selected, so the order is recorded in the same currency it was paid in.
"USD"
Stock reservation ids returned by POST /v1/checkout/reserve. Supplying them commits the stock already held for this shopper instead of decrementing it again, which is what keeps a high-demand drop from overselling between reservation and payment.
Delivery latitude, used to resolve the delivery zone or distance tier that prices shipping. Send it with shipping_longitude when the shopper's coordinates are known; the server re-derives the shipping cost from them rather than trusting a client total.
40.7128
Delivery longitude. See shipping_latitude.
-74.006
The id of the shipping rate the shopper chose, when rates came from a multi-carrier quote. The rate is re-fetched and validated server-side before it is charged, so a modified or stale rate is rejected rather than honoured.
"rate_8f2c1a9b4d7e4f109a3b2c5e7f1d0a44"
Where this order came from, recorded for the merchant's analytics. Accepts the fields below; the same fields are also read from the top level of the request body if you already send them there. Promotions that actually applied are recorded from the server-validated result, so promotion_ids never inflates what a shopper received.
Google ad click id, when the shopper arrived from a Google ad. On a paid order this lets the merchant's Google advertising get credit for the sale. Forward the true captured value; omit if not present.
"Cj0KCQiA...gclid"
Meta (Facebook & Instagram) ad click id, when the shopper arrived from a Meta ad. On a paid order this lets the merchant's Meta advertising get credit for the sale. The conversion is sent server-side (Conversions API) and de-duplicated against the storefront's Meta Pixel by the order id, so it counts even when the browser blocks the Pixel. Forward the true captured value; omit if not present.
"IwAR1abc...fbclid"
Advertising privacy-consent state captured at checkout, used to decide whether a conversion may be reported to an ad platform for this shopper's region (required for EEA shoppers; UK/Swiss records are not dropped for a missing signal). Always forward the true captured values β never guess.
Response
The Idempotency-Key has already been used for this store, so the order it created is
returned instead of a new one being made. The body is the order resource, exactly as
GET /v1/orders/{id} would return it β note this differs from the 201 envelope, which
nests the order under an order property.
Retrying a create with the same key is always safe: concurrent retries resolve to the
same order, and only the first request receives 201.
"ORD-2026-001234"
pending, processing, shipped, delivered, cancelled "pending"
pending, paid, failed, refunded "pending"
Method used for payment
stripe, paypal, paystack, mpesa, cash, bank_transfer "stripe"
1999.98
159.99
Per-jurisdiction tax detail when tax was calculated automatically for the shipping destination (one entry per taxing jurisdiction). Null when a flat store rate was used.
How the tax figure was produced β automatic (jurisdiction-accurate calculation for the destination), fallback (automatic calculation was unavailable, so the store's configured rate was used), or manual (the store's configured rate).
automatic, fallback, manual, null "automatic"
15
0
2174.97
Customer-visible updates the merchant added as the order moved β the work between payment and dispatch (preparation, checks, packing) that a shopper otherwise hears nothing about. Oldest first, so it reads as a timeline. Internal notes are never included.
The merchant's own fields on this order, with their values β a buyer's purchase-order number, a cost centre, whatever the merchant defined. Only fields the merchant published appear here; one holding an internal note or a cost stays in the admin. Empty when the merchant has defined none.
The merchant controls the names and how many exist, so render the array rather than reading fixed
keys: field_label is the heading to show, and field_type gives the shape of value.
Whether this order was created in the live or test environment. Sandbox orders are isolated from production data.
production, sandbox "production"
Complete shipping calculation details for audit trail

