Food Production / E-commerce Operations
A production-oriented integration service that turns Shopify order events into traceable Tabliya operations, with mapping controls, idempotency, retries, replay, and manual review built into the workflow.
Tabliya uses Shopify for online ordering and a separate operational platform for products, orders, payment methods, invoices, and production workflows. The two systems use different identifiers and data contracts, so transferring an order involves more than forwarding a webhook payload. The integration needed to cover the complete order lifecycle while giving operators a practical way to understand and recover from failures without creating duplicate records.
A direct Shopify-to-API call would leave several operational risks unresolved. Shopify can redeliver webhooks, events can arrive close together, and Tabliya requires its own product IDs and payment-method values. Addresses, delivery dates, discounts, payment state, updates, and cancellations also need deliberate transformation. If a product was not mapped or the destination API became unavailable, the system needed to preserve the event, stop an incomplete order from being created, explain the failure, and support a controlled retry after the underlying issue was fixed.
The service was designed as an auditable event pipeline. Shopify webhook signatures are verified against the raw request body before an event is accepted. Valid events are stored before processing, deduplicated by webhook and Shopify order identifiers, and handed to BullMQ for retryable background work, with an in-process fallback when Redis is unavailable. Product and payment mappings are maintained separately from order logic. The transformer resolves those mappings, normalizes customer and address data, calculates delivery dates, translates payment state, and refuses to create a partial destination order when a line item is unknown.
The TypeScript and Express service handles Shopify order creation, updates, payments, fulfillment changes, edits, and cancellations. It creates or updates the corresponding Tabliya order, stores both request and response context, and preserves the relationship between the two systems. Cancellation first uses a configured or detected Tabliya status, verifies the result, and falls back safely when required. Optional invoice synchronization is isolated behind configuration. A protected admin console exposes product and payment mappings, webhook events, synchronization logs, settings, unresolved exceptions, manual replay, and reconciliation tools. Operators can correct a mapping and retry the original event instead of rebuilding an order by hand or losing the audit trail.
Preventing duplicate Tabliya orders when Shopify redelivers the same event or an operator initiates a replay.. Translating Shopify products, variants, payment labels, addresses, delivery dates, discounts, and payment states into Tabliya's API contract.. Applying cancellation safely despite multiple possible destination status endpoints and preserving the cancellation reason and timestamp.. Keeping webhook acknowledgement fast while supporting retries, reconciliation, and useful failure visibility.. Blocking incomplete orders when a mapping is missing, then making recovery straightforward for an operator.
Established an idempotent order pipeline with stored raw events and explicit synchronization state.. Covered order creation, updates, payment and fulfillment changes, edits, cancellations, and optional invoice follow-up.. Created operator-managed product and payment mappings instead of relying on fragile title matching.. Added retry, replay, reconciliation, structured logs, and a manual-review queue for recoverable failures.. Verified the local build, health endpoint, protected admin access, invalid-signature rejection, and unmapped-product review path against an isolated PostgreSQL database.