Data Panda brings your Commerce Layer data together with the data from the rest of your business. From one place, we turn it into dashboards, automations, AI workflows and custom apps your team uses every day.
Commerce Layer started in 2017 in Italy, founded by Filippo Conforti (who built online commerce at Gucci before this) and Massimo Scardellato. Customers include Brioni, Chilly's, SumUp and Paradox Interactive.
The product is pure API. There is no admin storefront, no theme editor, no checkout page that ships with a logo slot. The merchant brings their own frontend (a Next.js build, an Astro site, a mobile app, sometimes a print catalog with QR codes) and Commerce Layer handles the cart, the order, the customer, the inventory, the price list, the shipment and the tax through REST and GraphQL endpoints. Payments stay outside: Stripe, Adyen, Braintree or PayPal sit next to it.
The data shape that follows from that choice is what makes the warehouse worth wiring up. Markets let one organization sell into Belgium, France and the US with different price lists, currencies, tax rules and stock pools, all on the same SKU catalogue. Price lists override per market and per customer group. Stock locations route fulfilment per market. None of that fits in a single OMS export, and the developer team that owns the storefront usually does not own the warehouse where finance and merch want to look at the same numbers.
One picture of margin, conversion and stock across markets, price lists and stock locations.
Keep Commerce Layer aligned with the PIM, payment processor and accounting around it.
Turn cross-market order history and price-list depth into forecasts and pricing suggestions.
Internal tools on Commerce Layer data for the people who do not live in the developer console.
A list of concrete reports, automations and AI features we have built on Commerce Layer data. Pick the one that matches your situation.
Which market is paying for the new storefront?
Margin per Commerce Layer market after returns, fulfilment from the routed stock location and payment-gateway fees, with the storefront source kept. Surfaces the launch market that looks busy in dashboards and runs a thin margin once the local tax category and shipping cost are folded in.
Has any price list drifted away from where finance signed it off?
Snapshot of price-list overrides per market and customer group against the agreed list price, with the date the override last changed. Catches the manual price tweak made for one campaign that was never rolled back, before a finance review does.
Are the SKUs in Akeneo the same SKUs Commerce Layer is selling?
Reconciliation between the Akeneo product master and the Commerce Layer SKU table, with attributes and per-market enablement visible. Flags the SKU that is enriched in the PIM but never published to a market, and the SKU live on a market without an updated PIM record behind it.
Margin per market and per price list with returns, fulfilment and gateway fees handled the same way, plus VAT per market ready for filing. Month-end stops waiting on a developer to query the Commerce Layer API for last week's orders.
Cross-market customer behaviour with cohort LTV and segment scoring per currency. Merchandising and growth see which market and which storefront earn the customer that comes back.
Stock cover per stock location and per market in one view, alongside fulfilment SLA and return rate per SKU. The market where stock routing slips or returns spike surfaces before the customer-service queue does.
Akeneo holds the product master with attributes, translations and media. Each enriched SKU pushes into Commerce Layer with the right market enablement and price list, so a new product goes live on the headless storefront without a developer pasting JSON into a script. The PIM and the commerce engine stop drifting on which SKUs exist and what they are called.
Commerce Layer captures the order and the auth, Stripe processes the payment and pays out per market currency. Bringing both into the warehouse matches each Stripe charge, refund and chargeback to the Commerce Layer order, with gateway fees and FX kept. Finance closes the month against one reconciled view instead of two exports stitched in a spreadsheet.
Commerce Layer order, customer and SKU events flow into Klaviyo as profiles and metrics, with the market and currency kept on each event. Winback, replenishment and loyalty flows fire on actual days-since-order per market, so a Belgian buyer and a US buyer of the same SKU get cadence that fits their behaviour, not a single global rule.
Commerce Layer orders, refunds and shipments arrive in Exact Online as sales invoices with the VAT category from the Commerce Layer market preserved, the gateway-net amount on the bank line, and the storefront tagged on the cost centre. The Belgian books match the Belgian market without a manual line-by-line check against the headless storefront.
These are the 10 tables we currently pull from Commerce Layer into your warehouse. Query them directly in SQL, join them to the rest of your stack, or build reports on top.
Missing a table you need? We can extend the sync. Tell us what is missing and we will build it for you.
You keep the reporting tool you already have. We connect it to the warehouse where your Commerce Layer data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
Each market lands as a first-class dimension with its own currency, price list and stock location reference. Reports can stay per market for local P&L, roll up to the organization for consolidated reporting, or compare a launch market to an established one without flattening the hierarchy.
Commerce Layer stores the payment authorization, the order total and the payment method, but the actual processing happens at the gateway. The connector pulls the order-side payment record from Commerce Layer, and the matching Stripe, Adyen or Braintree connector pulls the gateway side. Both sit in the warehouse so a join produces the reconciled view.
The storefront source is kept on each order via the channel and reference fields Commerce Layer exposes. Reports can split per storefront, group across storefronts that share a market, or compare a Next.js DTC build against a mobile app on the same SKU catalogue, without a separate connector per frontend.
We review your Commerce Layer setup and the systems around it. Together we pick the first thing worth building.