Skip to main content

Platform Architecture

MintID is designed around a set of principles that prioritise data integrity, tenant isolation, and minimal public disclosure.

Design Principles

1

Tenant isolation

Every brand operates in its own logical workspace. Data access is scoped to the brand level — users, products, identifiers, and jobs are all partitioned by brand.
2

RPC-first mutations

All write operations go through server-side functions rather than direct table access. This ensures validation, audit logging, and access control are applied consistently regardless of the client.
3

Immutable audit trails

Identifier changes, product updates, and administrative actions produce permanent audit records. Nothing is silently overwritten.
4

Minimal public disclosure

Public-facing endpoints (such as the resolver) return only the minimum data required — typically a UUID. No product details, pricing, or sensitive data are exposed without authentication.

Key Concepts

Workspaces and Brands

A brand is the primary organisational unit. Each brand has its own product catalogue, identifier space, team members, and configuration. Users can belong to multiple brands with different roles.

Roles

RoleScope
OwnerFull administrative control, including billing and team management
AdminProduct management, identifier edits, imports, and API credential management
Marketing EditorProduct attribute editing (non-identifier fields)
Compliance ApproverReview and approval workflows
ViewerRead-only access to products and settings

Identifier Architecture

Every product has an immutable system UUID. Mutable identifiers (SKU, GTIN, EAN, UPC) are stored as aliases with full change history. The public resolver uses a “forever valid” strategy — retired codes fall back gracefully so printed barcodes never break. See Identifiers for details.

DPP Schema

Product attributes are governed by a schema derived from your brand’s industry classification (NACE code). The schema defines which fields are required, their data types, and any value-set constraints. This schema drives mint readiness checks.

Integration Model

MintID exposes a set of authenticated RPCs for programmatic access:
  • Product management — create, update, and query products
  • Identifier management — read and write identifiers with history
  • Import workflows — upload, validate, and commit product data
  • Bulk updates — apply changes across many products asynchronously
  • Credential management — create and rotate API keys
All API operations require authentication. The only public endpoint is the Resolver, which returns UUIDs only.

FAQ

Product data is stored in a managed database with tenant-level isolation. All access is mediated through server-side functions with role-based access control.
Yes. Each brand is a fully isolated tenant with its own data, team, identifiers, and configuration.
MintID is currently offered as a managed service. Self-hosting is not available at this time.