Modes

Galactic Core is one commerce core that ships in three shapes. The vast majority of the API is identical across all three — the same catalog, cart, checkout, payments, customers, search, and webhooks — and each mode adds a small, focused surface on top for its shape. Most of an integration is therefore built once and reused across modes.

​

The shared core (build this once)

Whatever mode you target, these work the same way and are the bulk of any integration:

• Catalog & discovery — products, categories, product specifications, search, recommendations.
• Cart & checkout — cart, wishlist, orders, pricing, promotions, gift cards.
• Payments — the payment surface and its providers.
• Customers & identity — customer profiles and the two ways a shopper signs in (a Galactic Core session token, or your own identity provider). See Authentication.
• Everything operational — shipping, returns, reviews, messaging, content, analytics, tax, webhooks, and catalog ingestion.

If you’re building a normal single-store storefront, that shared core is the whole API — you don’t touch anything mode-specific.

​

What each mode adds

​

Vanilla GC (standard)

Vanilla GC is standard Galactic Core for a single merchant — one store you run yourself, on Galactic Core’s secure multi-tenant platform with strict per-store data isolation. It’s the default, and the one most integrations target. It adds nothing on top of the shared core: a merchant’s own storefront uses the shared services directly with the merchant’s own key.

​

Marketplace

A marketplace aggregates many independent merchants into one shopping experience. It authenticates with a single marketplace operator key; the standard catalog reads automatically span every active merchant (each result stamped with the merchant it came from), a single cart can hold items from several merchants, and one payment is split to each merchant automatically after checkout. Mode-specific surface: client.marketplace — see the Marketplace service.

​

B2B (Wholesale)

A wholesale store sells to business buyers at negotiated or tiered prices, often on payment terms. The negotiated path runs from request for quote to quote to purchase order to terms invoice, with buyer credit and payment on net terms. Buyer-facing actions form an API surface; the supplier prices quotes and manages the pipeline in their admin. An approved buyer reordering routine items does not need that round trip. A wholesale storefront therefore supports both flows: direct checkout against the buyer’s already-resolved price, and request for quote for negotiated or bespoke orders. A direct order returns a settlement of terms (a terms invoice was issued, and is paid against the invoice) or pay_now (the order awaits payment, completed against the returned order_id exactly like a retail order). Which one applies is resolved server-side from the buyer’s own terms and the supplier’s policy, so a storefront builds both paths and branches on that response. Wholesale is a per-store capability rather than a whole-deployment setting, so a retail store and a wholesale store can run side by side on the same standalone deployment. Each store’s commerce_model, returned by GET /v1/store/info, identifies which it is: retail for a standard cart-and-checkout storefront, or wholesale for the request-for-quote storefront. Because the value is per store, it is the reliable signal even when the deployment itself serves both kinds of store. Alongside it, a wholesale store reports a vendor_type — who the seller is, by position in the supply chain from upstream to downstream: supplier (raw materials, components, or unbranded goods sold to other producers), manufacturer (makes the finished product), distributor (an authorised reseller for a brand, usually in set regions), or wholesaler (buys in bulk and resells to businesses). It is null on a retail store. Price, minimum order quantity, and lead time all shift depending on which tier a buyer sources from, so the value carries commercial weight beyond labelling. Mode-specific surface: client.b2B — see the B2B service.

​

Where to go next

• Core Concepts — the ideas (keys, stores, environments, currency) that underpin every mode.
• Quickstart — make your first call.
• Authentication — API keys and shopper/buyer sessions.
• Sandbox & Test Environment — build and test safely before going live.
• Mode-specific: the Marketplace and B2B service pages.