E-Commerce API Integration: Products, Inventory, Catalogs, and Sales Channels Across Platforms
February 9, 2026
[E-commerce API](/commerce) integration is how a SaaS product reads and writes catalogue, inventory and storefront data across platforms like Shopify, WooCommerce and BigCommerce from its own code. This guide is for engineering teams building those integrations: which data models matter, how change events arrive, what to design around, and when to build each integration in-house versus use a unified API such as Unified.to's Commerce API, a pass-through API across 212 commerce integrations with no customer records stored at rest.
The full object and integration list is in the Commerce API overview. For a roster of individual platform APIs, see 15 E-Commerce APIs to Integrate With in 2026; to compare unified API platforms, see What Is the Best Unified API for E-Commerce Integrations?
Why are commerce integrations hard to build across platforms?
Commerce integrations are hard because each platform, from Shopify to WooCommerce and BigCommerce, structures products, variants, inventory and collections differently and sends change events unevenly. Each platform has its own APIs, object models, and update mechanisms. Products may be structured differently, inventory may be tracked at variant or location level, and collections or categories behave inconsistently across systems.
Products that need to support multiple commerce platforms quickly encounter:
- Incompatible product and variant schemas
- Platform-specific inventory models
- Inconsistent collection and category hierarchies
- Uneven webhook support for catalog and stock changes
A Commerce API provides a consistent way to read and write catalog and inventory data across platforms, without building and maintaining separate integrations for each provider.
What Is a Commerce API?
A Commerce API allows applications to programmatically manage and consume product-side e-commerce data.
In practice, this includes:
- Creating and updating products and variants
- Synchronizing inventory across locations and channels
- Managing collections, categories, and catalogs
- Retrieving storefront metadata and sales-channel configuration
- Aggregating product reviews and ratings
Commerce APIs focus on what is being sold and how it is stocked and presented. They are deliberately not responsible for orders, payments, customers, or fulfillment.
How does a Commerce API differ from Accounting, Payments, CRM, Marketing and Shipping APIs?
A Commerce API covers product-side data only; in Unified.to's model, orders and financial records belong to Accounting, money movement to Payments, people to CRM, audiences to Marketing and logistics to Shipping.
- Commerce APIs manage product catalogs: items, variants, inventory, collections, locations, reviews, and sales channels
- Accounting APIs manage financial records: orders, invoices, bills, journal entries, tax rates, and reports
- Payment APIs manage money movement: payments, refunds, payouts, subscriptions
- Shipping APIs manage logistics: shipments, labels, carriers, tracking, and rates
- CRM APIs manage people and relationships: contacts, companies, deals, and pipelines
- Marketing APIs manage audiences and campaigns: lists, members, and engagement data
Commerce data often feeds these systems, but Commerce itself never becomes the source of truth for finance, customers, or fulfillment. Any handoff across categories is explicit and application-controlled.
Should a commerce integration read live data or a synced copy?
Read live where stock and catalogue accuracy matter: inventory changes with every sale, so a synced copy is only as current as its last run. Commerce systems are highly dynamic. Inventory levels change with every sale, catalogs update throughout the day, and reviews are constantly added or moderated.
Live Access to Source Platforms
Unified's Commerce API routes every request directly to the underlying commerce platform. There is no stored replica and no background sync job. Reads reflect the current state of the source system, subject to provider rate limits and availability.
Update Delivery with Webhooks and Polling
Commerce platforms vary widely in event support.
- Some platforms emit native webhooks for product, inventory, or collection changes
- Others provide no webhooks at all
- Certain objects support polling only
Unified.to supports both native webhooks, forwarded when available, and virtual webhooks, which use polling-based change detection, on supported integrations and objects: for example, native item events on Shopify and ShipStation, and virtual item events on NetSuite and WooCommerce. For objects or providers without webhook support, applications poll list endpoints using incremental filters such as updated_gte.
Which commerce objects does Unified.to normalize, and how do they behave?
Unified.to normalizes commerce data into nine standardized objects. Field lists and per-integration support are in the Commerce API overview; the notes below cover behaviour to design for. Seven cover the retail catalog (Items, Item Variants, Inventory, Collections, Locations, Reviews, and Sales Channels), and two more, Reservation and Availability, extend the same schema to booking and hospitality commerce. Provider behavior varies, and integrations should be designed defensively.
Items (Products)
Items represent products in the catalog.
- Support create, read, update, and remove operations where providers allow
- Store internal and public names, descriptions, tax flags, vendor names, and metadata
- Carry collection references; variants point back to their item through
items
Some platforms restrict deletion or treat it as archiving rather than removal.
Item Variants
Variants represent sellable SKUs such as sizes or colors.
- Support full CRUD where providers allow
- Include SKU, pricing, options, physical dimensions, and visibility flags
- Track availability timing and shipping requirements
Variants carry a total_stock summary and an inventory_id; per-location stock lives in Inventory.
Inventory
Inventory represents stock levels at specific locations.
- Links items or variants to locations
- Stores current available quantity
- Updates frequently and is often latency-sensitive
Inventory writes are available on fewer integrations than reads, including Shopify, NetSuite, Walmart and ShipStation.
Collections
Collections group products into categories or catalogs.
- Support hierarchical structures via parent_id
- Control storefront visibility and merchandising
- May be read-only on some platforms
Locations
Locations represent warehouses, stores, or fulfillment points.
- Store address, currency, locale, and hierarchy
- Control where inventory is stocked and sold
Location creation or modification is often restricted by providers.
Reviews
Reviews represent customer feedback.
- Include rating, title, content, author details, and moderation status
- Support creation and moderation only where platforms allow
- Include verification flags and vote counts
Reviews may contain customer-generated content and should be handled carefully downstream.
Sales Channels
Sales channels define where products are distributed.
- Use a stable slug as the channel identifier
- Reference collections to control catalog exposure
- Are often fixed or read-only on marketplaces
Reservations
Reservations represent bookings at a location, for restaurants, venues, and appointment-based commerce.
- Support create, read, update, and remove where providers allow
- Store guest name, contact details, party size, start and end times, and staff assignment
- Link to a location and, optionally, a specific item
Reservation support comes from booking-oriented sources such as OpenTable, resOS, SevenRooms, Cloudbeds and Mews.
Availability
Availability represents open booking slots at a location.
- Read-only across every integration, since availability is computed at the source
- Lists open windows by location, time range, party size, and staff
- Used to drive booking search rather than to write state
Which cross-category references do commerce objects carry?
Commerce objects carry few cross-category references: items can link to an Accounting account (account_id) and tax rate (taxrate_id), and reservations and availability can carry a staff_user_id that references an HR employee.
- No CRM contact or company identifiers
- No payment or transaction references
- No marketing list or member linkage
All other relationships stay within the Commerce domain.
How do inventory and catalogue changes reach your application?
Inventory and catalogue changes reach your application as native webhooks where the platform sends them, virtual webhooks where Unified.to detects changes by polling, or your own polling with updated_gte.
Inventory Changes
Inventory updates are delivered through native or virtual webhooks where available, or retrieved via polling with updated_gte. Latency depends on provider capabilities and polling configuration.
Catalog Changes
Item, variant, and collection updates follow the same pattern. Native webhooks provide immediate updates when supported. Virtual webhooks introduce short delays.
Reviews and Moderation
Review creation and moderation behavior varies by platform. Many providers require polling to detect changes.
How does Unified.to handle commerce data and privacy?
Unified.to keeps no customer commerce records at rest: requests pass through to the source platform, and only connection credentials and operational metadata are stored, encrypted. Commerce data includes both business-sensitive and customer-generated information.
What does Unified.to store?
- No customer commerce records are stored at rest
- Connection credentials and operational metadata (endpoint, timing, status) are stored, encrypted
- One region per workspace: US on every plan; EU or AU on Pro and Scale
If persistence is required, applications store data themselves.
Sensitive Data Considerations
- Reviews may include names, emails, avatars, and free-text content
- Media assets may include embedded metadata
- Pricing, cost, and inventory levels are commercially sensitive
For AI-driven workflows, Unified MCP's hide_sensitive option strips sensitive fields such as names, emails and phone numbers before data reaches the model.
What do teams build with a Commerce API?
Teams use a Commerce API for multi-platform catalogue management, inventory sync, channel enablement, review aggregation and commerce analytics.
Unified Catalog Management
Manage products and variants across multiple platforms from a single integration.
Inventory Synchronization
Keep stock levels aligned across sellers, channels, and locations to prevent overselling.
Marketplace and Channel Enablement
Publish product catalogues consistently across storefronts and marketplaces.
Review Aggregation
Collect and analyze product feedback across platforms.
Commerce Analytics
Combine catalog, inventory, and channel data for reporting and forecasting.
What constraints should you design around?
Write support, event coverage and deletion behaviour all vary by platform, so design for partial support from the start.
- Write support varies by provider
- Inventory updates may lag on polling-only platforms
- Reviews often have moderation and write restrictions
- Deletions may be soft-deletes or archives
- Platform feature parity is uneven
These constraints reflect real commerce platform behavior and should inform system design.
Should you build commerce integrations in-house or use a unified API?
Build in-house when you support one or two platforms that are central to your product; use a unified API once you need many platforms behind one schema. To compare unified API platforms, see What Is the Best Unified API for E-Commerce Integrations?
Building In-House
- Multiple APIs to maintain
- Inconsistent product and inventory models
- Custom polling and retry logic
- Ongoing maintenance as platforms evolve
Using a Unified Commerce API
- One category-specific API surface
- Normalized catalog and inventory models
- Live access to source platforms
- Centralized authentication and maintenance
- Usage-based pricing: Grow from $750 a month (750K API calls), Pro $1,500 (2M), Scale $3,000 (6M), with unlimited connections and a 30-day free trial on Grow and Pro
What are the best practices for commerce integrations?
Keep commerce integrations to product-side data, design for partial write support, and prefer webhooks over polling where they exist.
- Treat Commerce as product-side data only
- Design for provider variability and partial write support
- Use webhooks where available and poll selectively
- Keep catalog concerns separate from orders and payments
- Restrict access to sensitive pricing and review data
Build commerce integrations with clean boundaries
If your product relies on product catalogs, inventory levels, and storefront configuration across multiple platforms, maintaining separate commerce integrations quickly becomes complex and error-prone.
Unified's Commerce API provides a consistent way to manage items, variants, inventory, collections, locations, reviews, and sales channels, with no customer records stored at rest and without collapsing category boundaries.
→ Start your 30-day free trial
→ Book a demo