tieback Architecture Overview | tieback API Documentation

tieback is structured as a SaaS platform for Digital Product Passport and product identity workflows. Its architecture separates identity, resolver logic, lifecycle events, and API access into clear modules so organisations can scale from compliance preparation to high-assurance authentication without reissuing identifiers.

Platform Architecture

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

Design Principles

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.

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.

Immutable audit trails

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

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

Role	Scope
Owner	Full administrative control, including billing and team management
Admin	Product management, identifier edits, imports, and API credential management
Marketing Editor	Product attribute editing (non-identifier fields)
Compliance Approver	Review and approval workflows
Viewer	Read-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

tieback 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

Where is product data stored?

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.

Is the platform multi-tenant?

Yes. Each brand is a fully isolated tenant with its own data, team, identifiers, and configuration.

Can I self-host tieback?

tieback is currently offered as a managed service. Self-hosting is not available at this time.

Core architectural layers

Identity layer (SKU and item-level records)
Resolver layer (GS1 Digital Link support)
Lifecycle event logging
API access and integration controls