Standalone catalogue & sync boundary

Flexible catalogue data. Stable where it matters.

Prologus gives every source one controlled path into a canonical catalogue. Complete revisions are validated and activated atomically, so consumer applications always read stable product data.

Discuss your catalogue See the revision workflow

Catalogue revision source · 184

Complete source snapshot

Ready to activate

Validated

identityresolved✓

catalogue graphvalidated✓

consumer contractcompatible✓

Active nowRevision 183

One transactionRevision 184

Readers stay on revision 183 until revision 184 commits.

Grocery provenThe first complete configuration, without baking grocery names into the core.

Full snapshot importsEvery revision describes the complete state for one source boundary.

Atomic activationReaders get the old catalogue or the new one—never a partial import.

Consumer-ready readsProducts, facts, stores, current prices, and offers behind scoped tokens.

Who Prologus is for

Teams that have outgrown passing source data straight to the storefront.

Catalogue & ingestion leads

When each importer has become its own catalogue.

Move stable identity, taxonomy, revision history, and activation rules into one owned boundary without centralizing scraper internals.

Platform & API teams

When consumers depend on source-specific schemas.

Publish one versioned contract for products, facts, organizational scope, prices, offers, filters, and nearby discovery.

Consumer product teams

When “current product data” is not a dependable state.

Read a fully activated catalogue and independent regular, public-offer, and loyalty price facts without reconciling upstream evidence.

The system boundary

Keep harvesting upstream. Keep catalogue truth here.

Prologus is not another scraper, PIM screen, or storefront. It is the owned boundary where normalized source records become a coherent catalogue contract.

Prologus ownsCanonical catalogue state

Stable identity: Permanent product UUIDs resolved from existing source mappings, real GTINs, identity keys, or a new master.
Catalogue structure: Brands, category trees, category-defined attributes, related products, media, and localized names.
Commercial context: Retailer, market, region, and store hierarchies with regular prices and time-bounded offers.
Activation boundary: Immutable staged records, full-graph validation, transactional materialization, and revision history.

Stays outsideSource and consumer concerns

01 Scraper state, source evidence, enrichment, and product correlation decisions
02 Checkout, baskets, customer accounts, and consumer-application state
03 On-hand stock, reservations, replenishment, fulfilment, and warehouse workflows
04 Reconciliation of conflicting upstream claims inside storefront clients

The result: ingestors can change without rewriting consumers, and consumer products can evolve without inheriting source-specific data models.

Complete revision workflow

Prepare the next catalogue while the current one stays live.

Each source publishes full snapshots. Staging is idempotent and invisible; activation is the only moment live catalogue state changes.

01 POST /v1/sync/batches
Open a source revision

A lifecycle-managed caller token opens one revision and receives a short-lived batch token.
02 PUT /v1/sync/{entity}
Stage typed records

Upload entities in any order. Retrying the same source key replaces that staged payload safely.
03 POST /v1/sync/validate
Resolve the whole graph

Identity, references, taxonomy, typed metadata, prices, and organizational scope are checked without touching live rows.
04 POST /v1/sync/activate
Switch atomically

Only changed records are materialized, omitted source-owned records retire, and the active batch changes in one transaction.

Operational surfaces

Inspect revisions. Manage catalogue state. Exercise the contract.

Prologus includes an administrator interface for catalogue operations and an API Explorer built from the same versioned HTTP boundary. These representative views use the actual product navigation and contract terminology.

groceries-nl-jumbo

Revision 184

ValidatedActivate revision

Stateready

Source boundaryretailer-country

Import shapefull snapshot

Visibilitystaged only

EntityValidationMaterialization

organizational_unitResolvedPending activation

productResolvedPending activation

product_metadataResolvedPending activation

price / discountResolvedPending activation

API Explorer

Test the same contract consumers integrate.

Browse the public OpenAPI document, provide a scoped read token, and exercise catalogue examples without maintaining a separate documentation application.

GET/v1/products/nearby

latitude=52.3676
longitude=4.9041
radius_km=8
limit=20

200 OKactivated catalogue only

{
  "products": [ ... ],
  "applied_filters": {
    "radius_km": 8
  }
}

Catalogue model

A generic core with structured product facts.

Grocery retail proves the shape, but retailer and store are configurations—not hard-coded limits.

Product identity

One master, many source keys

Source records converge on permanent product UUIDs without losing their original identities. Explicit merges remain possible and auditable.

source mapping → GTIN → identity key → new UUID

Taxonomy & metadata

Categories define the fields

A primary category drives an inherited schema of typed attributes: text, integer, decimal, boolean, date, or stable option values.

category → category_attribute → product_metadata

Structured facts

Food and packaging stay meaningful

Localized ingredients, nutrients, Nutri-Score, sellable measures, dimensions, and packaging components retain their proper structure.

food profile · nutrients · package · components

Organizational scope

Prices follow the real hierarchy

Typed recursive units model retailer, market, region, and physical store. Store reads inherit applicable ancestor prices and offers.

retailer → market / region → store

Measured read paths

Performance claims tied to a reproducible catalogue.

July 2026 local benchmark against an activated 17,435-product revision. These are development measurements—not a universal SLA—and the repository includes repeatable benchmark tasks for every read path.

17,435 products in the activated revision under test

16.361 ms 100-product list with brand, category, unit, and Nutri-Score

0.658 ms one product’s structured food profile and nutrient rows

70.349 ms 100 products from the largest category browse

85–122 ms 100 balanced nearby regular prices, measured end to end

Reproduce locally task benchmark:metadata · task benchmark:reads · task benchmark:api

Versioned read API

Give consumer applications a contract built for presentation.

The read API exposes only activated state. Named pla_ tokens expire, record use, and can be revoked without granting any sync capability.

Opaque cursor pagination for stable product traversal
Filters derived from active brands and category-defined attributes
Independent regular, public-offer, and loyalty price facts
Nearby discovery with inherited retailer and regional prices
A public OpenAPI 3.1 contract and readiness endpoint

Catalogue read API /v1

GET /products

Browse by name, brand, category, GTIN, identity, or typed attribute.

GET /product?public_id={uuid}

Product profile, localized names, facts, media, relations, and price history.

GET /products/nearby

Consumer-ready products at physical stores within a geographic radius.

GET /prices/nearby

Effective regular and promotional prices with balanced or explicit sorting.

GET /openapi.json

Machine-readable contract; public by design.

Adoption path

Start with one source boundary and one consuming application.

Prologus can be introduced between an existing normalized feed and an existing consumer. The first implementation proves identity, revision activation, and the read contract before more sources move across.

01
Define the boundary
Choose a complete retailer-country, supplier, or equivalent source snapshot with stable source keys.
02
Map the catalogue graph
Project organizations, categories, attributes, brands, products, facts, prices, and offers into typed sync records.
03
Prove activation
Validate and activate revisions alongside the current path. Restore historical revisions without editing history.
04
Move one consumer
Integrate the versioned read API, filters, product profile, and relevant discovery or pricing endpoints.

Deployment shape

A small operational footprint with explicit dependencies.

Application: Go HTTP service
Canonical state: PostgreSQL
Media: Local or S3-compatible storage
Contracts: Versioned HTTP + OpenAPI 3.1
Access: Separate lifecycle-managed sync and read tokens
Operations: Health endpoint, migrations, revision inspector, API Explorer

Your deployment, your data

Run Prologus where it works for your organization.

Choose a managed service operated by us or deploy Prologus inside your own infrastructure. The product and catalogue contract stay the same, so deployment policy does not become application lock-in.

Hosted by us

A managed Prologus environment.

We operate the application and its catalogue infrastructure while your team connects sources and consumer applications through the same supported contracts.

Managed application lifecycle
Operational support from the product team
A focused path from evaluation to production

Your infrastructure

Customer-owned deployment, backed by us.

Run Prologus on-premise, in your private cloud, or in your preferred environment. Keep infrastructure and data under your control while retaining implementation and operational support.

Your security and data-residency policies
Your PostgreSQL and storage environment
Supported upgrades and implementation guidance

Bring your own environment. Start managed and move in-house—or begin in your own environment. Prologus is designed around portable application, database, storage, and HTTP contracts. Discuss deployment options

Official partner

Catalogue infrastructure meets the consumer experience.

Scontivo is Prologus’ official consumer partner, turning dependable catalogue, price, and offer data into a focused shopping experience.

Visit scontivo.com

A focused technical session covering sources, identity, revision boundaries, consumers, and rollout risk.

Review your catalogue architecture.

Request an architecture review