Name one system of record for each type of data before you connect anything. Stock, orders and customer records each need one owner — the system whose numbers are truth when storefronts disagree. Two stores can sell in parallel safely, but only when one system owns the truth, the other reads from it, and you have tested what you can export before you need to.
Two live storefronts raise a search question — see our guide on two-store SEO cannibalisation. This guide stays on operations.
The short answer: name one system of record per data type before you connect anything (table)
Decide this table in writing before the second store opens:
| Data type | System of record (choose one) | The other storefront |
|---|---|---|
| Stock / inventory | Platform, own store, or ERP — one only | Reads stock; never holds its own count |
| Orders | The system where fulfilment and refunds are worked | Mirrors orders for visibility only |
| Invoices | One invoicing flow, integrated with ZATCA | Issues no invoice of its own |
| Customer records | One customer list of record | Passes new customers in |
| Product catalogue | One catalogue of record | Receives published products from it |
A row with two owners, or none, is where the business will fork.
The failure mode: two storefronts, one warehouse, no owner of the truth
The fork is quiet at first. One warehouse, but each store keeps its own stock count, so a platform promotion sells units the own store has already promised. Orders live in two dashboards: fulfilment picks from whichever list someone opened, and a refund is processed in whichever system the agent checked — sometimes twice.
Customer records split the same way: half the buyers exist only on the platform, half only in the own store, and neither list is complete enough to market to or audit. Invoicing splits too. This default outcome, when no system owns the truth, surfaces at the first oversell or dispute.
Stock: one inventory truth, two selling surfaces — allocation and oversell rules
Physical stock is one pile, so its record must be one count. Choose where it lives — platform, own store, or ERP behind both — and make every other surface read it. A storefront keeping a local copy "just for display" will eventually sell from it.
Then set allocation rules for the moments sync cannot save you. Hold a safety buffer below true stock on fast-moving lines, so a delay cannot sell the last unit twice. Decide which channel wins a simultaneous sale — the order timestamped first in the record — and what the losing customer is offered: a wait, a substitute or an immediate refund. In peak seasons, consider hard allocations: a fixed quantity per storefront instead of both drawing on one pool.
Orders: where an order is born, where it is fulfilled, and where the invoice comes from
Follow one order through its life and name a system at each step. An order is born on whichever storefront the customer used. Fulfilment is worked from one queue: both storefronts feed one operations view, or staff work one named dashboard per channel — but no order is actionable in two places. Refunds are processed in the system that owns that order's record, against its original payment and invoice.
Invoicing is strictest. ZATCA describes the tax invoice as usually issued business-to-business and the simplified tax invoice as usually issued business-to-consumer, with Phase Two requiring integration with ZATCA's systems (zatca.gov.sa). Two storefronts therefore need one invoicing flow of record: both channels feed it, it issues each invoice once, and credit notes reference the original invoice there. Two invoice sequences for one business is an audit problem. Our ecommerce development services treat this single-flow design as part of the build.
Customer data: what you actually own on Salla and Zid, and what "export" really gives you
On a hosted platform, customer records live inside the platform's system, under its terms: you have access and export routes, not the database. Per each platform's own documentation: Salla's developer documentation (docs.salla.dev) describes Merchant APIs covering orders, products and Exports — including an orders export endpoint returning xlsx or csv files — via OAuth2. Zid's developer documentation (docs.zid.sa) describes Merchant APIs for orders, products, inventories and customers, plus webhooks, and a products export delivered as a CSV file by email or via Export Requests.
That defines what "export" really gives you: structured files and API access to defined entities — not your store's full working state. Passwords, payment tokens, loyalty balances, app data and platform analytics do not travel in a customer file. Before running two stores, export each entity you depend on, open the files, and check the fields are there. Holding customer data across two processors also raises your data-protection duties; see our overview of GCC data protection laws.
Sync reality: APIs, middleware and manual exports — direction matters more than speed
Three mechanisms connect two storefronts; they are not interchangeable. APIs and webhooks — documented by both platforms — move data automatically and are the only sound basis for stock and orders. Middleware can bridge the stores, but adds a system to pay for and monitor; treat it as a named cost category — see the guide on the three-year cost of platform versus own store. Manual exports are acceptable for a catalogue refresh and dangerous for stock: the file is stale the moment it is saved.
Whatever the mechanism, direction is the discipline. Stock flows out from the record to both storefronts; orders flow in to the order owner; customer records merge into the list of record under a written duplicate rule. Two-way sync of the same field guarantees conflicts. Speed matters less than direction: a five-minute one-way sync preserves the truth; an instant two-way sync forks it faster. Businesses that outgrow hand-built sync formalise it through custom web application development.
The three workable models: platform-led, own-store-led, or ERP-led
Platform-led: Salla or Zid stays the system of record; the own store is a brand surface handing order flow back into the platform's truth. Simplest to run, and right while most sales happen on the platform.
Own-store-led: the own store owns stock, orders and the customer list; the platform store becomes a satellite channel fed from it. This suits merchants whose own store is the main business — a common shape with a web development partner in Saudi Arabia.
ERP-led: neither storefront owns the truth; an ERP behind both holds stock, orders, invoicing and customers. It is the heaviest model and the only honest one at high volume or with branches, because storefronts never owned the truth and cannot fork it. If the own-store build is still being scoped, see our guide to ecommerce website development in Dubai.
The exit test to run before you need it: a full export, restored and checked
Ownership untested is a hope. Once a quarter, and before renewing either store, run the exit test: export products, customers and orders in full from both systems, open every file, restore it into a test environment, and check counts, fields and totals against the live dashboards. Note what did not export — that is your real lock-in.
Keep dated exports somewhere the business controls, outside both platforms. If a dispute or failed renewal cuts access, the last tested export separates an inconvenience from losing the customer list.
When the honest answer is one store, not two
Two storefronts earn their complexity only while each does a job the other cannot: the platform brings an audience, the own store brings brand control. When one storefront's sales no longer justify the sync, the invoice risk and the split customer list, consolidate. The next step is the migration — see moving off Salla or Zid to your own store — which assumes these ownership questions are settled.
Common mistakes when adding a second storefront
Connecting the stores first and deciding ownership later. Letting both storefronts hold their own stock count "temporarily." Issuing invoices from both systems. Assuming a customer export contains everything, without opening the file. Syncing the same field in both directions. And naming no one to check the two dashboards still agree.
FAQ
Can Salla or Zid and my own store share one stock count?
Yes, if one system is named the inventory record and the other storefront only reads from it, via the platforms' documented APIs, webhooks or middleware. Two local counts is the failure mode: each store sells against its own number, and overselling follows, especially in a promotion.
Who should issue the ZATCA invoice when orders come from two stores?
One invoicing flow of record, fed by both storefronts. ZATCA distinguishes the tax invoice, usually for business buyers, from the simplified tax invoice, usually for consumers, and Phase Two requires integration with ZATCA's systems — so each order is invoiced once, in that flow, with returns credited against the original invoice there.
What do I actually get when I export customer data from Salla or Zid?
Per the platforms' own documentation, structured exports and API access to defined entities — Salla documents an orders export in xlsx or csv via its Merchant API, and Zid documents a products export as a CSV file. Passwords, payment tokens and app data do not travel. Export, open and restore-test the files before relying on them.
Is two-way sync between the two stores a good idea?
Not for the same field. Sync stock out from one record, orders in to one owner, and customers into one list of record, each one-way with a written duplicate rule. Two-way editing of the same data guarantees conflicts, because neither system can tell which change is the truth.
When should we consolidate back to one store?
When one storefront no longer does a job the other cannot — its sales stop justifying the sync, the second invoice risk and the split customer list. Consolidation is a planned migration with exports tested first, not switching a store off and discovering what the export missed.
Get the ownership architecture designed before the second store launches (CTA)
If you are adding an own store beside Salla or Zid, have the system-of-record table, sync directions and exit test designed before the first order crosses both systems. Start with our ecommerce web development services and bring your platform details, catalogue size and stock location — we will map which system should own stock, orders and customer data.
