Skip to main content
Galactic Core — GC — is programmable commerce infrastructure: the engine that runs the commerce, and the operational layer around it. Catalog, cart, checkout, payments, tax, inventory, double-entry accounting, search, recommendations, promotions, gift cards, returns, messaging, content and analytics are all part of the platform, reached through one REST API and a typed TypeScript SDK. The storefront is yours. Bring a web front end, a mobile app, an AI-generated storefront or a backend service; call the API, and the commerce logic behind it — inventory math, order lifecycle, payment capture, tax resolution, ledger entries, fulfilment — is already handled.

​
Who Galactic Core is for

GC is the layer other commerce businesses are built on, so the answer to “is this for me?” depends on what you are running rather than how large it is.

A merchant selling direct

You need a real store — products, checkout, payments, tax, returns, books — without assembling it from separate services. Build the front end yourself, or generate one with Anvil and connect it to the same API.

A wholesaler selling to businesses

Your buyers negotiate. Quotes, purchase orders, invoices, net terms, per-buyer price lists and credit limits are part of the platform rather than a spreadsheet beside it. See B2B.

Someone running a marketplace

Many sellers behind one storefront, one cart spanning several of them, and a single shopper payment split to each seller at capture. See Marketplace and Marketplaces at Scale.

An agency or software company

Your customers are merchants. Run GC as your own commerce platform — your brand, your domain, your plans and prices, your merchants — with the engine out of sight. See Agencies.
The agency case covers more kinds of company than the name suggests: development studios building storefronts for clients, marketing agencies who want the commerce behind the campaigns they already run, and software companies generating front ends with AI that need a deterministic commerce backend underneath. What they share is that the merchant is their customer, and GC stays out of sight. Every one of these runs on the same engine. What differs is who the operator serves — see Deployment Modes for how a deployment is configured for each.

​
Building with an AI agent

Storefronts are increasingly written by an agent rather than typed by hand, and an agent needs a backend whose behaviour is fixed and whose contract it can read. Every endpoint, request and response is published as an OpenAPI specification and a generated SDK, so an agent works from what is deployed rather than from what it recalls. Inside the platform, the assistant works the same way. It prepares gift cards, promotions and pricing rules from a store’s own data as drafts a human approves, and refuses actions it cannot cover — see Agentic commerce for what it can and cannot do on its own.

Quickstart

Make your first authenticated call and render a product in a few minutes.

Deployment Modes

Vanilla, marketplace and B2B — what each adds, and which one a deployment runs.

TypeScript SDK

A type-safe client covering every service, with retries, pagination, and HMAC built in.

Core Concepts

Keys, environments, isolation, edge caching, and how money flows.

​
What you can build

The API spans 29 services across ~145 operations, grouped by the job they do. A typical storefront calls a handful of them.

Catalog & Discovery

Products, variants, specifications, collections, categories, AI semantic search, and hybrid recommendations (similar, also-bought, next-likely, trending, personalized, bundles).

Cart & Checkout

Persistent carts and wishlists, dynamic pricing, promotions, gift cards, shipping rates, and idempotent order creation with automatic inventory and accounting side effects.

Payments

Multi-provider payment initiation and verification (Stripe, PayPal, and regional processors), with sandbox test mode built in.

Customers & Auth

Customer profiles and RFM analytics, plus customer authentication via native sessions or your own identity provider (bring-your-own-auth).

Returns & Support

Shopper-initiated returns and store credit, and real-time customer↔store messaging.

Content & Storefront Analytics

Shoppable blog posts and lookbooks, and first-party traffic / funnel / revenue analytics captured without a third-party tracking script.

Marketplace

Aggregate many merchants behind one storefront, with a unified cart and a single payment that splits to each merchant automatically.

B2B (Wholesale)

Sell to business buyers at negotiated or tiered prices, on terms — request for quote, quote, purchase order, and invoice, with credit and payment on net terms.

Agentic commerce

Your in-app assistant prepares gift cards, promotions, and dynamic-pricing rules from your store’s own data as drafts you approve, protects your margin, and tidies your catalogue directly.

Native integrations

Payment processors, ad platforms, catalog channels, shipping, accounting, messaging and tax — connected with a merchant’s own credentials, and open to any provider through an extension.

Global by default

Per-store currency, multi-currency catalogs, and geographic pricing — currency always read from store info, never assumed.

​
Properties of the platform

One coherent contract

A single auth model, one error shape ({ error: { code, message } }), cursor pagination, and sparse field selection hold across every endpoint, so a convention learned on one is the convention everywhere.

Commerce, not just storage

Orders create journal entries, reduce stock, redeem gift cards, and update customer metrics automatically. You call one endpoint; the operational side effects are handled.

Edge-first performance

Reads are served from a multi-tier edge cache, so catalog and pricing calls return in tens of milliseconds worldwide.

Tenant isolation

Row-level security keeps every store’s data private on the shared platform; marketplace and enterprise tenants run on a dedicated stack of their own. See Core Concepts.

Built-in sandbox

Every endpoint has a test environment keyed by your API key — build and test against realistic data without touching production.

Build a storefront

The SDK is consumable by AI storefront builders, so a complete, commerce-wired storefront can be produced from the API surface alone.
Behaviour under load, and what happens when something fails, is covered in Scaling & Reliability — and for a marketplace, where thousands of sellers share one storefront, in Marketplaces at Scale. The limits on automated and AI-driven actions are in Guardrails.

​
Two ways to integrate

TypeScript SDK (recommended)

npm install @tybrite-labs/sdk → a typed client with a method per endpoint, automatic retries, cursor pagination helpers, idempotency, and HMAC signing. Ideal for web and Node.js apps.

REST API

Call https://api.tybritelabs.com directly from any language or runtime. Bearer-key auth, JSON in/out, served from the edge.
Other language SDKs (Python, Go, Rust) and React storefront components are on the roadmap.

​
Authentication at a glance

Galactic Core uses two key types — a full overview is in Authentication:
  • Publishable keys (tybrite_pk_*) — read-only, safe in the browser (catalog, search, cart writes).
  • Secret keys (tybrite_sk_*) — full read/write, server-side only (orders, payments, customer data).
Shopper-specific actions add a customer session (a GC-issued token, or your own bring-your-own-auth assertion). Sensitive writes (orders, payments, ingestion) are additionally HMAC-signed.
Need help designing your architecture? Reach the team at support@tybritelabs.com.