E-Commerce API notes
There is one API for the whole platform. There is no separate E-Commerce API, no separate host for it, and no storefront-only key. For the path grammar, access endpoints, authentication, paging, response envelopes and error codes, read the developer integration path:
Integrate an external system →
Every mapping the backend has is under core2/, and the tenant-scoped ones this module uses are
under core2/tnt/dm/… (Core2Config.TENANT_DOMAIN_URL_PREFIX). Nothing below is a substitute for
that page; it is the e-commerce-specific part.
The document types this module produces
| Server document type | Produced by | Quantity · amount signum | Meaning |
|---|---|---|---|
INTERNAL_SHOPPING_CART (short code SHPCRT) | storefront checkout, Customer Access, Shopping Cart (Internal) | 0 · 0 | A pre-order. No journal, no stock |
INTERNAL_SALES_ORDER | server conversion of a paid cart, staff knock-off of a FINAL cart, marketplace order-ingestion jobs | 0 · 0 | The order. Counts against available stock; no journal, no stock |
INTERNAL_RECEIPT_VOUCHER | GEN_DOC_PGW_RECEIPT_VOUCHER_PROCESSOR after a gateway callback; the Shopee, TikTok Shop and Lazada payout jobs | 0 · −1 | The money. Posts to the cashbook and the debtor; belongs to Financial Accounting |
A seller order (bl_mkp_seller_order_hdr) is not a server document type: it is a
marketplace-table record with its own controller (mkp/seller-orders), no journal and no stock
processor. A payment-gateway transaction (bl_fi_generic_doc_pgw_txn) is likewise a record
attached to a document, not a document.
The sales invoice, delivery order and return that follow are Sales document types, and their signums are on that page.
Endpoint families an integration touches
| Family | Path (under core2/tnt/dm/) | What it is |
|---|---|---|
| Back-office carts | erp/gen-doc/internal-shopping-carts | The generic-document controller the Shopping Cart (Internal) applet uses: create, save, update-posting-status (FINAL), delete |
| Customer-scoped carts | ecom/internal-shopping-carts | The controller the Customer Access applet uses: one cart per customer entity, the login must be linked to the entity (SHOPPING_CART_ALREADY_EXIST otherwise) |
| Storefront carts and checkout | cp-commerce/internal-shopping-carts | The storefront’s own cart endpoint, whose service converts a paid cart to a sales order and handles point purchases |
| Gateway payments against any document | erp/gen-doc-pgw-payments | Reserve a payment reference for a document and get the signature the gateway expects; the gateway’s callback then queues the receipt-voucher processor |
| Payment channels and providers | pgw/paymentchannels, pgw/payment-providers, pgw/contracts, pgw/contract-rates | The master data the Payment Channel applet maintains and the storefront reads for its provider list; the provider endpoints have public/… variants the storefront calls anonymously |
| Media | fm/drives, fm/files | Tenant drives and files behind the Media Library applet |
| Sales orders | erp/gen-doc/internal-sales-orders | Ordinary sales orders; see Sales |
Each family carries the platform’s permission model (owner / admin / member / read on the entity)
and the login-entity-ep variants where a customer, seller or merchant login is scoped to its own
entity.
The marketplaces and gateways that exist
These are the third-party platforms with code in the backend. Nothing else may be named as an integration on any page of this module.
| Kind | Platforms | Where the code is |
|---|---|---|
| Marketplaces | Lazada, Shopee, TikTok Shop, Shopify — full or partial sync cycles; Magento — product retrieval service only | akaun-api … jobProcessor/custom/ecomSync, jobProcessor/ecomsync; see the EcomSync index for which step each has |
| Payment gateways | iPay88, PayPal, FPX | controller/tenant/dm/pgw/… and domain/paymentGateway/… |
The marketplace connectors are jobs, not endpoints: an integration cannot call “sync to Shopee”; it can create the scheduler record that makes the job run, or write the listing and order records the job reads.
Two things an integration must respect
- Signum 0 means what it says. Writing an
INTERNAL_SALES_ORDERthrough the API creates an order and nothing else. If your integration expects stock to move or revenue to post, it must create the sales invoice (Sales), or leave that to the warehouse. - A cart’s line integrity is checked at checkout, and revisions are checked on save. The
storefront’s conversion runs
verifyCartLineIntegrityAtCheckoutbefore it creates the order; a cart edited after the reference was generated fails. Read the revision back before you PUT, as every applet in the platform does.
What the API will not do for you
- Post a gateway fee, or reconcile a payout against orders (§4 of Core Concepts).
- Reserve stock on checkout.
- Trigger a marketplace sync on demand.
- Serve a storefront: the Customer Portal is a separate application configured per website in CP Commerce Admin, not an API product.