Orders

Technical details for partners integrating with the Event Bridge system to receive real-time order event notifications via webhooks. Our service processes orders and sends it to your provided endpoint

Prerequisites

To integrate, our team will work with you to configure:

  1. Your Webhook URL: A secure HTTPS URL endpoint on your system capable of receiving HTTP POST requests with a JSON payload.

  2. Shared Secret (Generated by Us): We will generate a unique, secure secret string for your specific webhook configuration. This secret must be used by you to verify the HMAC signature on incoming requests. We will provide this secret to you securely.

  3. Custom Headers (Optional): You can specify any additional HTTP headers (key-value pairs) you require us to include in the webhook requests (e.g., for static authentication tokens or routing). We will store and send these with each request, provided they don't conflict with essential headers.

Webhook Request Details

Our service will send events to your configured Webhook URL using the following specifications:

  • Method: POST

  • Headers:

    • Content-Type: application/json

    • User-Agent: liquid-commerce-event-bridge-service/1.0

    • x-liquid-commerce-event-type: The type of event (e.g., order).

    • x-liquid-commerce-hmac-sha256: The HMAC signature (see Security section).

    • x-liquid-commerce-idempotency-key: A unique identifier for this specific webhook delivery attempt, generated by our service.

    • x-liquid-commerce-delivery-id: A unique identifier for this delivery, constructed from order identifiers and a timestamp.

    • x-liquid-commerce-timestamp: An ISO 8601 timestamp indicating when the webhook was sent by our service.

    • Any custom headers you provided during setup.

Payload Structure (event-type: order)

The request body is a complex JSON object representing the transformed and serialized order data. The following structure, but may be simplified for documentation clarity. Refer to specific fields relevant to your integration.

Key Fields & Notes:

  • Identifiers: referenceId, partnerId, retailers[].id, items[].id, etc., are our internal relevant identifiers.

  • Timestamps: All timestamps are in ISO 8601 format (UTC).

  • Payload Granularity: The payload contains details potentially aggregated across multiple internal entities (orders, shipments, fulfillments, retailers). The retailers array allows for orders fulfilled by multiple retailers. Each retailer has its own fulfillments, packages, and amounts.

  • Status Fields: Note the different status enums used at different levels (e.g., fulfillments[].status vs. packages[].status). Use the status most relevant to your needs.

  • Amounts: Amounts are provided at the top level (order total) and broken down within amounts.taxDetails, amounts.discountDetails, and also within each retailers[].amounts. Item-level pricing is in items[].pricing.

  • Optional Fields: Many fields are optional (nullable) depending on the specific order details (e.g., giftMessage, deliveryInstructions, legacyOrderNumber, referenceId). At least referenceId or legacyOrderNumber will be included and for hybrid orders you'll receive both.

  • Additional Headers: Our service includes a few additional headers for traceability and idempotency assistance:

    • x-liquid-commerce-idempotency-key: A unique UUID for each delivery attempt. While you must implement your own idempotency based on payload content (like referenceId and updatedAt), this key can be useful for logging and tracing specific delivery attempts on your end.

    • x-liquid-commerce-delivery-id: A unique identifier for this delivery, typically formed using order identifiers and a timestamp. Useful for tracing.

    • x-liquid-commerce-timestamp: An ISO 8601 timestamp marking when the webhook request was initiated from our service.

Headers (Recap)

  • Content-Type: application/json

  • User-Agent: liquid-commerce-event-bridge-service/1.0

  • x-liquid-commerce-event-type: e.g., orders

  • x-liquid-commerce-hmac-sha256: (If secret provided) Base64 encoded HMAC-SHA256 signature.

  • x-liquid-commerce-idempotency-key: Unique identifier for the delivery attempt.

  • x-liquid-commerce-delivery-id: Unique identifier for the delivery.

  • x-liquid-commerce-timestamp: Timestamp of when the webhook was sent.

  • Any custom headers you specified.

Expected Partner Response

Your webhook endpoint must respond promptly to acknowledge receipt.

  • Success: Respond with an HTTP 2xx status code (e.g., 200 OK, 202 Accepted, 204 No Content).

    • Respond immediately after validating the signature (if applicable) and before performing complex/long-running business logic to avoid timeouts. Our service treats any 2xx as success for the delivery attempt.

  • Failure: Respond with an HTTP 4xx (Client Error) or 5xx (Server Error) status code if:

    • The signature verification fails (respond with 401 Unauthorized or 400 Bad Request).

    • Your service encounters an error preventing acceptance (e.g., temporary overload, validation error on your side).

Retry Mechanism & DLQ

If your endpoint:

  1. Responds with a non-2xx status code.

  2. Times out (default: 5000ms).

  3. Experiences a network connectivity issue.

Our service will automatically retry 3 times with exponential backoff delays: 1000ms, 2000ms, 4000ms (approximately).

If the event delivery fails after the initial attempt and all 3 retries (total 4 attempts), the original event payload and error details will be sent to our internal Dead Letter Queue (DLQ) which purges after 7 days. No further delivery attempts will be made for that event. Consistent failures indicate an issue with your endpoint that needs investigation.

Idempotency

While we have internal mechanisms, the nature of our Distributed Event Streaming System with at-least-once delivery guarantee means you might receive the same logical update via multiple webhook calls.

It is CRITICAL that your system implements idempotency checks to prevent duplicate processing. Use a combination of identifiers from the payload relevant to your use case. A good candidate is the top-level referenceId combined with a relevant timestamp like updatedAt, or specific fulfillment/package IDs if processing at that level.

Example Check: Before processing, check if you've already successfully processed an update for referenceId with the same or an earlier updatedAt timestamp. If so, respond 2xx OK but skip processing.

Security: HMAC Signature Verification

You must verify the x-liquid-commerce-hmac-sha256 header on every incoming request using the unique Shared Secret we provide.

  • Algorithm: HMAC-SHA256

  • Encoding: Base64

  • Data Signed: The raw, unparsed JSON request body (exactly as received, including whitespace).

Verification Steps:

  1. Retrieve the raw request body bytes.

  2. Compute the HMAC-SHA256 hash of the raw body using the Shared Secret we provided.

  3. Encode the resulting hash in Base64.

  4. Securely compare (using a timing-safe comparison function) your calculated signature with the value from the x-liquid-commerce-hmac-sha256 header.

Failure to implement and correctly verify this signature poses a significant security risk, potentially allowing attackers to send fraudulent data to your endpoint.

Example: Basic Webhook Receiver

Here are conceptual examples demonstrating the core logic (signature verification, immediate acknowledgment, asynchronous processing) in various languages. These examples focus on the essential security and request handling aspects. Refer to the "Webhook Request Details" section for a comprehensive list of all headers your endpoint will receive, including informational headers like x-liquid-commerce-idempotency-key. Adapt the business logic, error handling, logging, security practices, and asynchronous mechanisms to your specific framework and production needs.

Node.js (Express)
Python (Flask)
Go (net/http)
Java (Spring Boot)
PHP

Support

If you encounter issues during integration or have questions about the webhook format or behavior, please contact [email protected].

Last updated