Skip to main content
First confirm the systems should actually be separate apps. Tightly coupled experiences — customer site, POS, kitchen display, back office — usually belong in one app with Surfaces, not multiple projects. When you already have genuinely independent apps that need to work with the same data, you have two options: connect them to a shared data store, or have them call each other’s APIs. This page helps you pick the right mechanism after that boundary decision.

​
The Short Version

Share a data store when independent apps need the same data and neither one “owns” it alone. Use cross-app calls when one independent app needs to tell another to do something, or when the apps have their own data but need to exchange specific pieces of it.

​
When to Share a Data Store

A shared data store works best when separate apps are different operators of the same underlying data. They all read and write the same tables, and changes show up everywhere instantly. Good examples:
  • Storefront + independently operated inventory service — both need the same catalog and stock tables, but they are owned and released as separate products.
  • Partner portal + internal ops console that must remain separate apps — same core records, different owners or compliance boundaries that prevent a single app.
  • Two products that deliberately share a curated data domain — for example reporting and billing products that both hang off the same finance tables.
The pattern: the apps are separate for a real ownership or product reason, yet they still share a data model. If you only need different audiences or devices on the same product, prefer Surfaces in one app instead of multiple apps on one store.

​
When to Use Cross-App Calls

Cross-app calls work best when the apps are independent systems that occasionally need to interact. Each app has its own data and its own purpose. Good examples:
  • Storefront + independently owned accounting product — the storefront owns orders; accounting owns ledgers and tax periods. When an order is paid, the storefront tells accounting to create a journal entry.
  • Commerce app + third-party fulfillment product — commerce owns the cart and payment; fulfillment owns warehouses and carriers. Commerce sends shipment requests; fulfillment sends tracking updates back.
  • CRM + invoicing — the CRM tracks deals, the invoicing app generates and sends invoices. When a deal closes, the CRM tells the invoicing app to create an invoice.
The pattern: the apps could exist independently. They have different data models and different responsibilities. They trigger actions in each other at specific moments.

​
Decision Guide

Still unsure whether you need multiple apps at all? Return to When to Create a Separate App.

​
Using Both

Some setups use both. Two independent products might share a data store for a curated domain, but use cross-app calls to notify a separately owned fulfillment or accounting system when something happens. The third system has its own data — it just needs to know when to act.