Tenant isolation
Every merchant’s data is isolated, and the isolation never depends on application code remembering to filter. On the shared platform, row-level security in the database scopes every read and write to a single store, so a query cannot reach another store’s data even on a shared table. Tenants who need physical separation rather than a logical one — a marketplace operator, an enterprise client — run on a dedicated deployment: a separate database and API layer whose incident cannot affect another tenant. Both are covered in depth in Data Model & Multi-tenancy. A merchant’s own automation — a custom extension, or an AI-generated one such as an ad-optimization rule — does not get direct database access when it needs to read the store’s data. It reads a governed set of business concepts (revenue and margin by product, stock at risk, campaign performance, active promotions, and the like) exposed as a fixed, read-only interface. Every concept is scoped to the automation’s own store and returns computed business facts rather than raw records, so an automation can act on detailed signals without being able to reach another tenant’s data or a table it was not meant to see. Which store a row belongs to and which staff member may act on it are separate questions, and both are answered in the database. Each staff member’s role determines which tables they may read and write — resolved on the server for every request and applied as a database policy per operation, so reading a record and changing it can require different permissions. A cashier can complete a sale without being able to open the general ledger or alter a customer record, and that holds regardless of what the interface offers, because the boundary is enforced beneath the application rather than inside it. Roles are per store and fully customizable: a store defines the roles it needs, and the permissions attached to each are what the database enforces.Authentication and access
Access to the API is by key, and the key type determines what it can do.Publishable keys
For the storefront — safe to ship in a browser or mobile bundle. A publishable key reads catalog and
other non-sensitive data, and can make the writes a shopper performs on their own behalf: adding to a
cart or wishlist, submitting a review, sending a message, lodging a return, updating their own profile.
It cannot place or modify orders, take payments, sign customers in, or touch store-wide or other
customers’ data.
Secret keys
Full read/write access, for server-side use only. Orders, payments, customer sign-in, and any
store-management write require a secret key — which must never reach the browser.
Data in transit and at rest
All API traffic is served over HTTPS/TLS; there is no plaintext endpoint. Sensitive values a merchant stores with the platform — payment-processor credentials, integration tokens — are encrypted at rest in a managed secrets vault, not in an ordinary table column, and the plaintext is never returned to the browser after it is entered. What the merchant sees afterward is a masked reference; the secret itself is used only server-side, to talk to the provider it belongs to.Payment integrity
The payment path is designed so that the platform never holds funds and never sees raw card details.1
Card details go straight to the processor
Card entry happens on the payment processor’s hosted checkout, not on a Galactic Core page. Card
numbers never reach the platform’s servers or database — the platform stores only a payment reference,
never a card number.
2
The processor holds the money
For marketplace payments, funds are captured by the processor and paid out to each merchant’s own
connected account. The platform never custodies money; it only directs the split. This is what keeps
marketplace operators outside money-transmitter territory.
3
Amounts are recomputed server-side
Prices, tax, shipping, discounts, and the order total are re-derived from the authoritative catalog
when an order is placed. A client that submits a tampered price or total is rejected — the amount the
customer is charged is the platform’s figure, never the client’s.
4
Payment confirmations are verified at the source
When a payment is confirmed, the platform re-checks the transaction directly with the processor and
reads the amount and status from the processor’s own response. Provider webhooks are cryptographically
signature-verified, and a notification that fails verification — or arrives without a signature — is
rejected before it can affect an order.
Running your own code safely
Custom integrations let a merchant’s own code participate in the platform’s flows, which means the platform treats that code as untrusted and bounds what it can reach and how long it can run.1
Merchant code never shares an isolate with platform code
A hosted handler runs in its own sandbox with no platform credentials, no database connection, and no
access to another store’s data. Its provider secrets are held in an encrypted vault and injected for the
duration of a single invocation.
2
Outbound requests cannot reach internal addresses
Any URL a function calls — and any endpoint registered for remote execution — is checked before the
request is made. Loopback, private, link-local, and cloud-metadata addresses are refused, so a function
cannot be used to probe infrastructure from the inside.
3
Nothing runs unbounded
Every invocation has a hard timeout, a cap on outbound calls and response size, and a per-store monthly
ceiling. A function that repeatedly fails is disabled automatically, and one that is slow or errors on a
checkout path is bypassed rather than allowed to block a sale.
4
What a function returns is not taken on trust
A returned payment status, tax figure, or shipping amount is revalidated against the platform’s own
authoritative data before it affects an order. A custom provider cannot mark an order paid, discount a
total, or alter an amount by asserting it.
Inbound provider callbacks
An extension can be given a URL for providers that report results asynchronously. Because that URL is publicly reachable and triggers merchant code, it carries its own controls. The URL embeds a 32-byte random secret held only as a hash, so it cannot be derived from a database read and cannot be guessed. On top of that, each extension declares how a caller proves its identity: a verified signature where the provider signs its callbacks, or an allow-list of the provider’s source addresses where it does not. A request that fails any of these checks — including one that simply omits a required signature — is refused, and every refusal is recorded in the extension’s run log so a misconfiguration is visible rather than silent. Failures are answered identically to an unknown URL, so the endpoint cannot be used to discover which extensions exist. The payload itself is treated strictly as input. The store, environment, and extension are resolved from the URL, never from a field in the body, so a callback cannot name a different store, select a different extension, or raise an amount. Callbacks are rate-limited per extension and size-bounded, and a lost or leaked URL is revoked by generating a replacement, which invalidates the previous one immediately.Environment separation
Test and live data never mix. The key prefix chooses the environment —tybrite_sk_test_ /
tybrite_pk_test_ operate on isolated sandbox data, …_live_ on production — and the two are stored under
a separate environment marker so a test order can never appear in live reporting. Sandbox data is purged on
a schedule, so test runs don’t accumulate. Because the environment is fixed by the key, there is no way for
a live key to read sandbox data or the reverse.
Data protection and privacy
The data in a store belongs to the merchant, and the tools to exercise GDPR and CCPA data-subject rights over it are self-service: the merchant runs them directly, from their own dashboard, without going through us. A store’s data is never shared with anyone else; we would only step in to help produce an export if a merchant were unable to run one themselves.Access and portability
A merchant can export a complete copy of their own store’s data — customers, orders, catalog,
accounting, and the rest — as a portable archive of spreadsheets, from Settings → Data Export, with
sensitive credentials excluded. They can also produce the data held about an individual customer to
satisfy a request that customer makes to them.
Erasure
A merchant can delete an individual customer’s personal data, and can request deletion of their entire
store. Erasure removes the personal data across the stores where it lives.
Stores on an operated platform
A store can belong to a platform run by an agency rather than directly to Galactic Core. Everything on this page still applies to it unchanged — the isolation, the payment integrity, the environment separation are properties of the platform, not of who sold the store. What that arrangement adds is an operator layer with controls of its own: the agency holds its own registrations for the outside tools its merchants connect, a merchant’s own account credentials remain scoped to that merchant’s store, and the agency’s consequential settings — pricing, billing credentials, integration credentials — require a fresh confirmation code rather than a live session. Those controls are described for operators in Running your own platform.Shared responsibility
The platform secures the infrastructure and the boundaries; you secure how your integration uses it. The split:Found a security issue? We appreciate responsible disclosure — email
security@tybritelabs.com and we will work with you on it. Please give
us a chance to address it before any public disclosure.
Authentication
Key types, scopes, environments, and request signing in detail.
Data Model & Multi-tenancy
How row-level security and dedicated deployments keep tenants separate.