Start building with OpenPX.

The OpenPX^™ schema is live and open. Validate a product against it today, with the JSON Schema tools you already use.

Join the developer waitlist See the schema → What's available today →

Reference it

Point your product at the schema.

{
  "$schema": "https://schema.openpx.org/v0.7.0/openpx-schema.json",
  "openpx": "0.7.0",
  "product": { "...": "..." }
}

Validate it

# Python
pip install jsonschema
python - <<'PY'
import json, urllib.request, jsonschema
schema = json.load(urllib.request.urlopen("https://schema.openpx.org/v0.7.0/openpx-schema.json"))
doc = json.load(open("my-product.json"))
jsonschema.Draft7Validator(schema).validate(doc)
print("valid")
PY

# JavaScript (ajv, draft-07)
npx ajv-cli validate -s <(curl -s https://schema.openpx.org/v0.7.0/openpx-schema.json) -d my-product.json

Current schemav0.7.0

Machine manifestindex.json

For AI agentsllms.txt

Exampleproduct.json

Codegithub.com/openpx-org

Built on Git

Your product data lives in Git repositories you own.

OpenPX is built on Git. An organization's products, variants and listings are JSON files in its own repositories, so every change is a commit with full history, and anyone you grant access can review and verify the data with standard Git tools. Register your repositories with OpenPX: public ones so anyone can verify your products, private ones for your team and your trading partners.

Public

Released products and public listings, signed by the organization. Anyone can verify each product's signature.

Partner

Shared with one trading partner: partner-specific terms and listings. Only your organization and that partner can read it.

Internal

Everything: drafts, costs, supplier data and connector configuration. Private to your organization, and the source the other tiers are promoted from.

The CLI · Ships with early access

# create a repository, its CI workflows and an Ed25519 org key
openpx repo init --tier internal --with-workflows --generate-key

# check an entity against the schema
openpx validate catalog/my-product.json

# sign active entities, then verify against .openpx/keys/
openpx sign --status active
openpx verify --all

# promote: internal → public and partner repositories
openpx promote run --filter visibility=public

Promotionpublic → public repo · restricted → authorized partners · private → never leaves

RuleConfidential data never enters a public repo

HistoryEvery change is a commit

PortableData, history and signatures move with the repo

Reference hostGitHub (built on Git, not tied to it)

Connectors

Build and register your own connectors.

Connectors move product data between your repositories and other systems. Publisher connectors bring data in from a PIM, ERP or file; consumer connectors send listings out to a channel. They run as CI workflows in your own repositories, with credentials kept in your repository's secrets, so OpenPX never sits in the middle.

# scaffold a connector: mapper, config and tests
openpx connector new --type consumer --name my-channel

Join the developer waitlist

PublisherPIM · ERP · API → your repo

ConsumerYour repo → channel

File connectorsFile in · file out (CSV, EDI 832, XLSX)

Runs inYour repo's CI

MappingsDeclarative mapping.yaml

Define · The data model

One model, from the organization to each channel listing.

An OpenPX document is JSON validated against a versioned JSON Schema (draft-07). Every document declares the schema version it was written against in its openpx field.

Organization→Brand→Product+Variant→Listing, per channel

Products and variants

A product carries identifiers (SKU, GTIN, UPC, EAN, MPN, model number), classification, attributes, physical specifications, media, compliance and warranty. A variant is a sparse override: it holds only the fields that differ from its parent product.

Listings

A listing is a product as one channel sees it: it references its product_id and names its channel and channel_account_id, with channel-specific content, availability and shipping, plus syndication status for that channel.

Identifiers

Every entity id is a UUID v7 (RFC 9562): time-ordered, so ids sort by creation time and index well. Organizations and brands carry their own external identifiers alongside.

Sign · Verify

Ed25519 signatures over a canonical form.

The organization signs each entity with its Ed25519 key. The signature covers the entity's fields in canonical JSON, so the same data always produces the same bytes, and any change to a single value breaks verification.

"signature": {
  "key_ref": ".openpx/keys/acme-2026-10-01.pub",
  "algorithm": "Ed25519",
  "value": "<base64 Ed25519 signature>",
  "signed_at": "2026-10-17T14:02:11Z"
}

AlgorithmEd25519

Signed bytesCanonical JSON of the entity

Canonical formSorted keys · UTF-8 · NFC

Excludedsignature, provenance

Public keys.openpx/keys/ in the organization's repo

Content hashSHA-256 of the canonical form

A valid signature proves

The entity was signed with the key the organization publishes.
No field has changed since it was signed.
Its history is on record: every change is a commit in the organization's repository.

It does not prove

That every value is correct. Accuracy stays the organization's responsibility, now attributable to it.
That a channel will accept the listing. Channel rules are checked separately, before publishing.

Developer preview: the canonicalization rules are specified by the OpenPX SDK and may be refined before version 1.0.

Publish · Mapping and channels

Map once to OpenPX. OpenPX is mapped to each channel's taxonomy, attributes, values and units.

Inbound, a brand's own catalog (PIM, ERP or spreadsheet) is mapped to OpenPX attributes, values and units, with AI-suggested mappings held for human review. Outbound, OpenPX categories and attributes are mapped to each channel's taxonomy, and listings are checked against the channel's requirements before they are sent.

Channel taxonomiesAmazon · Shopify · Google, with industry taxonomies in progress.

Mapping levelsCategory · attribute · value · unit

UnitsConverted to each channel's accepted units

Readiness checksAmazon (preview)

InboundPimcore · CSV

Versions and integrity

Immutable, addressable, verifiable.

How the schema is versioned and served

Version scheme: vMAJOR.MINOR.PATCH. Each published version is served at its own URL and never changes.
Schema identity: The schema's $id is its versioned URL, for example https://schema.openpx.org/v0.7.0/openpx-schema.json.
Latest: /latest/openpx-schema.json is a moving alias to the newest version. Pin a version in production.
Integrity: Every version has a published .sha256 file, and index.json lists every version with its hash and status (current or superseded).
Media type: application/json; profile="urn:openpx:v0"
For AI agents: llms.txt maps the registry for language models and agents.

SDK and CLI · Early release

Coming to the package managers you use.

The OpenPX SDK and command-line tool are on their way. Today's early releases carry the schema address and hold the names; signing, verifying and publishing follow.

Developer waitlist

Build and register your own connectors.

Tell us what you'd build, and we'll invite you as the CLI, SDK and repository registration open.

We only use what you send us to contact you about the developer waitlist.