Skip to main content
PARIXDocs
Security

Gateway-only boundary

How Parix authorizes and routes customer requests without exposing TigerBeetle replicas.

Every customer database operation uses the Parix gateway path. Developer, Dedicated, Production, and Enterprise do not expose raw TigerBeetle replica addresses or a direct native-protocol connection as a product surface.

Request path

For the public TigerBeetle operation API, the current path is:

  1. A client calls the Parix HTTP endpoint.
  2. web-app authenticates an API key or supported first-party OAuth token.
  3. Parix verifies organization membership, credential scope, target database access, and required db:read or db:write scope.
  4. Plan and shared-database quota checks run where applicable.
  5. Parix resolves the database profile, provider, and region.
  6. The request is forwarded through the configured provider-specific gateway binding and tunnel path.
  7. The provider-local tb-gateway validates the internal request and performs the TigerBeetle operation.

The public operation route is:

POST /api/v1/databases/{databaseId}/tb/{operation}

See TigerBeetle operations for supported operations and request bodies.

What customers can address

Customers address:

  • the Parix application/API endpoint
  • an organization and database identifier
  • a supported operation

Customers do not receive:

  • replica IP addresses
  • provider-local gateway or tunnel addresses as application endpoints
  • a raw TigerBeetle control-plane API
  • a native TigerBeetle protocol route to replicas

Private health, tenant-routing, and signed provider routes are operator infrastructure, not public integration endpoints.

Authorization layers

Gateway-only routing does not replace credential scoping.

LayerQuestion it answers
User/sessionIs this a signed-in Parix account?
Organization membershipDoes the user or referenced key owner still belong to the organization?
API key metadataIs the key organization-wide or bound to this database?
API scopeDoes the credential include the required read or write scope?
Plan enforcementIs this operation and request volume allowed for the database plan and status?
Provider routingWhich configured gateway path owns this database?

Use a database-scoped key even though every request passes through the gateway. The gateway is a routing and enforcement boundary, not a substitute for least privilege.

Explicit non-guarantees

This page documents the supported customer access boundary. It does not establish or promise:

  • a particular encryption-at-rest implementation
  • customer VPC peering, PrivateLink, or another private-ingress product
  • a compliance certification
  • cross-region availability
  • a contractual retention or recovery objective

Those properties must be documented by the applicable product capability or customer contract. See Providers and regions for currently exposed deployment choices.