Platform & API products
How SMOKESTACK's domain-owned APIs fit together, and how to choose the right integration boundary.
One platform, distinct product owners
SMOKESTACK publishes domain-owned integration products, not a broad public POS API. A shared credential or approved customer grant may reach more than one product, but it does not merge their authority or make one product a second source of business truth.
- Customer owns identity, consent, and customer-controlled connections.
- Commerce owns quotes, checkout intents, orders, and fulfillment state.
- Payments owns payment intents, instruments, rail behavior, and reconciliation.
- Inventory owns stock positions, packages, movements, transfers, and receiving.
- Compliance owns normalized decisions, regulator submissions, and evidence provenance.
- Reporting owns projections, completeness, and presentation—not the underlying domain facts.
Start with a published contract
Partner Data describes location-scoped, read-only incremental synchronization. Partner Ecom describes storefront catalog, availability, quotes, checkout intents, and orders. Customer Connections describes a customer-controlled connection protocol, not a customer directory. Each reference's selected revision and operation badges determine its documented contract maturity.
Only products in the public contract registry receive API reference pages. The roadmap covers other product boundaries without inventing base paths, methods, SDK calls, or delivery dates. An internal endpoint is not a public integration contract.
Keep admission, authorization, and availability separate
Gateway admission controls credentials, quotas, and analytics. The owning product still resolves the authoritative partner assignment, location, permitted operation or dataset, and revision. Caller-supplied resource identifiers cannot expand that assignment. Customer-personal access additionally needs the appropriate active customer grant.
Contract maturity comes from committed schemas; runtime availability requires separately published deployment and health information. This static portal reports runtime status as unavailable until that input exists. Neither a published contract nor a healthy service creates permission to call it.
Marketing is not customer lookup
Audience Activation is a separate, higher-trust product boundary: consented audience counts, opaque membership, suppression-aware activation, or managed delivery. A marketing credential must not become customer search. Medical status is not an audience segmentation field.
Any future record-level CRM export needs its own retailer-admin grant, purpose and retention controls, field scopes, opt-out enforcement, and export audit. A Customer Connections grant does not silently authorize that export.
Public documentation and future management tools
These references and guides are public. Application registration, credential management, assignments, quota analytics, and connection management belong to a separately authenticated integrator dashboard. Its planned design does not put a login in front of documentation or imply that those management tools are available now.