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.
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"
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
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
Order created successfully (or existing order returned if idempotency key matches)
Present only when store credit was applied to this order. The amount of the customer's store credit spent against the order.
25
Optional. Present only when one or more post-order processing steps (gift card redemption, stock reduction, etc.) failed. The order itself was created successfully, but a downstream side effect needs human follow-up. Each warning indicates the stage that failed and a human-readable message.

