---
title: "Feature Matrix | OpenEPCIS Docs | OpenEPCIS - an open-core, GS1-compliant EPCIS implementation."
canonical_url: "https://openepcis.io/de/docs/platform-overview/feature-matrix"
last_updated: "2026-06-28T23:26:18.035Z"
meta:
  author: "benelog GmbH & Co. KG"
  description: "OpenEPCIS capabilities by edition, aligned to the relevant GS1 standards."
  "og:description": "OpenEPCIS capabilities by edition, aligned to the relevant GS1 standards."
  "og:title": "Feature Matrix"
  "twitter:description": "OpenEPCIS capabilities by edition, aligned to the relevant GS1 standards."
  "twitter:title": "Feature Matrix"
---

</h2>Home

``

# **Feature Matrix** OpenEPCIS capabilities by edition, aligned to the relevant GS1 standards.9 min read Legend: `**✓**` = available · `**✓ (basic)**` = available with limitations; see notes · `**✓ (variant)**` = available in a build variant · `**partial**` = building blocks present, not fully wired end-to-end · `**roadmap**` = planned, not yet started · `**—**` = not in this edition. Capabilities are grouped by the seven module families the platform is organised around — Resolver, Masterdata, EPCIS Events, Formats & Validation, Integration, Access Control, Testdata, Platform. The deeper stories (multi-tenant isolation at the data layer, live subscriptions, the SAX converter) live on the [Architecture](https://openepcis.io/docs/platform-overview/architecture) and module-group pages. ## GS1 Conformant Resolver The full GS1 Conformant Resolver ships in the business edition. The OSS rows below are the building blocks for working with GS1 identifiers — URN ↔ Digital Link translation, barcode rendering, identifier validation. | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | GS1 Conformant Resolver (multi-tenant, REST) | — | ✓ | One deployment serves many brand owners; partners and consumers integrate using standard GS1 link types, no bespoke clients. | | Self-describing deployment | — | ✓ | Implements the GS1 Conformant Resolver discovery contract — downstream registries (the GS1 Global Office resolver, partner systems) find the deployment and read what it offers automatically, no hand-configuration needed. Served at `**/.well-known/gs1resolver**`. | | A dozen GS1 link types auto-derived from masterdata | — | ✓ | Save a product once and the resolver derives the standard link relations (`**gs1:pip**`, `**gs1:productImage**`, `**gs1:certificationInfo**`, `**gs1:productSustainabilityInfo**`, `**gs1:safetyInfo**`, `**gs1:instructions**`, `**gs1:nutritionalInfo**`, `**gs1:recallStatus**`, `**gs1:serviceInfo**`, `**gs1:audioFile**`, `**gs1:relatedVideo**`). No manual linkset POST per product. | | Bulk CSV / JSON-LD linkset import | — | ✓ | First-time onboarding path — tens of thousands of products in a single call. | | Tenant-scoped masterdata cache | — | ✓ | Keeps resolution fast under multi-tenant load; each customer's hot path stays in cache without crossing tenants. | | Linkset change audit | — | ✓ | Who changed which linkset, when — what regulated brand owners need to satisfy due-diligence and traceability reviews. | | EPC URN ↔ Digital Link translation | ✓ | ✓ | For interop with legacy systems still emitting `**urn:epc:id:…**`; same library powers URN-on-demand at query time. | | QR / Data Matrix / GS1-128 barcode generation | ✓ | ✓ | One Digital Link URI rendered into any GS1-conformant barcode — pick by use case (QR for consumer scans, DataMatrix for small parts, GS1-128 for cartons). | ## GS1 Web Vocabulary & Masterdata | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | GS1 Web Vocabulary data model (libraries) | ✓ | ✓ | Java types for the GS1 Web Vocabulary — useful when building integrations or generating documents outside the platform. | | Masterdata REST API (`**/organizations**`, `**/products**`, `**/places**`) | — | ✓ | Platform discipline: masterdata lives on the resolver, never embedded inside EPCIS events. One source of truth, no duplication, no contradictory copies. | | **Full "Verified by GS1" integration with GS1 Germany services** | — | ✓ | Bidirectional. Inbound: verifies a GTIN or GLN against GS1 Germany's registry (Activate Plus / GEPIR) and enriches the local record with authoritative party / product attributes. Outbound: publishes the brand owner's masterdata back into the GS1 network — the deployment acts as source-of-truth and the records propagate up to the GS1 Global Office resolver. A real node in the GS1 trust graph. | | **Event → Resolver masterdata promotion** | — | partial | The internal masterdata bus exists; what's missing is the bridge from `**/capture**` into it. Once landed, an EPCIS event will register new masterdata implicitly — closing the "events drive masterdata" loop. | ## EPCIS Events: Capture · Query · Subscriptions | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | EPCIS 2.0 REST `**/capture**` | — | ✓ | Single endpoint for any volume — documents are validated, hashed, deduplicated and stored in one pipeline. | | EPCIS 2.0 REST `**/query**` (Named Queries) | — | ✓ | Filter by EPC, biz-step, location, time window; queries can be stored, named, and re-run by partners without re-sending the criteria each time. | | EPCIS 2.0 SOAP binding | — | ✓ | For partners still on the EPCIS 1.x message bus — same backend, different envelope. | | Hash-based event deduplication | ✓ lib | ✓ | Resending the same event produces the same ID. Capture is idempotent — safe to retry after a network hiccup without doubling up the event store. | | Streaming subscriptions (live, no polling) | — | ✓ | a match fires the moment an event is indexed. No poll interval, no missed window, no "did I get that one yet?" debate. | | Scheduled subscriptions | — | ✓ | Cron-style delivery for partners that prefer batch-style — nightly digests, periodic compliance pulls. | | WebSocket delivery | — | ✓ | Push channel for browsers and lightweight clients. | | Webhook delivery | — | ✓ | Standard HTTP POST to any partner endpoint. | | Digital Link canonical form at rest, URN on demand | — | ✓ | Stored once in Digital Link form. Clients still on EPC URN form get it rendered on demand — no double storage, no drift between formats. | | Reliable paginated queries that survive reconnects | — | ✓ | A six-month export can disconnect and resume on the same scroll cursor — important for regulators and big partners pulling long histories. | | OpenSearch backend | — | ✓ | Primary store — open source, scales horizontally, supports the percolator queries the live subscriptions ride on. | | Elasticsearch backend (variant) | — | ✓ variant | For deployments where the customer's existing observability or compliance posture already standardises on Elasticsearch. | | High-volume capture variant | — | ✓ | Headless capture pipeline for environments where events arrive over Kafka rather than HTTP — the REST front-end is replaced by a stream consumer. | ## Formats, Validation & Identity | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | XML ↔ JSON-LD conversion | ✓ basic | ✓ | OSS: XSLT, load-then-transform — fine for the common cases (single events, small batches, plain shapes). Business: SAX-streaming — multi-gigabyte exports, deep extension trees, complex sensor payloads, mixed-format batches. | | EPCIS 1.2 ↔ 2.0 XML migration | ✓ basic | ✓ | OSS: the XSLT converter handles straightforward migrations. The Business edition adds the SAX converter — the production-grade path used to migrate live 1.2 corpora to 2.0. | | EPCIS document validation | ✓ | ✓ | Catches malformed events at the boundary so they never land in the event store. Cheaper than discovering the problem six months later in a query result. | | Custom-extension validation across the event | — | ✓ | For organisations with proprietary fields that need to coexist with the GS1 vocabulary — extensions are validated at every nesting level of the document. | | Sensor element validation | — | ✓ | Makes sensor payloads structurally trustworthy — units, value types, device IDs all checked at capture time. | | Pre-canonical event hash (idempotent event IDs) | ✓ | ✓ | The hash is computed against a normalised representation of the event — whitespace, attribute order, JSON key order don't affect the ID. Re-sends and round-trips through different serialisers produce the same event ID. | | Web UI for format conversion | — | ✓ | Browser-based for non-technical users — drag in an XML or JSON-LD file, get the other format back. Same engine as the API. | | Hash generator as a service | — | ✓ | REST endpoint for partners who want canonical event IDs without running the converter locally. | ## Integration & Gateways | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | S3-compatible storage | ✓ lib | ✓ | Any object store that speaks the S3 API — AWS S3, on-prem implementations, S3-compatible appliances. | | Azure Blob storage | — | ✓ | First-class option for Azure-native deployments — no S3 gateway in front. | | File upload / download service | — | ✓ | REST endpoint for bulk inputs and outputs that are too large to fit comfortably inside JSON payloads. | | AI assistant (Ollama-backed) | — | ✓ | Ask "show me last week's events for GTIN X" in plain English; the assistant classifies the intent (EPCIS query, identifier resolve, vocabulary lookup) and returns a translated EPCIS query plus the answer. Local LLM by default — no third-party API dependency. | ## Access Control (cross-cuts every business deployable) | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | OIDC, session-cookie, and API-key authentication | — | ✓ | Three credential shapes, one identity. Customers pick whichever fits their stack — OIDC for IdP-integrated systems, cookies for browser UIs, API keys for service-to-service traffic. | | Per-customer (tenant) isolation in Keycloak | — | ✓ | Each customer gets their own realm — user accounts, groups, roles, and policies don't bleed across customers. Resolved automatically from the request's hostname. | | Data-layer tenant isolation (OpenSearch DLS) | — | ✓ | the application doesn't rewrite queries to add a tenant filter. The data layer itself enforces isolation, so even if app code is wrong, customer data stays separated. | | Role-based access (`**capture**`, `**query**`) | — | ✓ | Two roles ship out of the box — `**capture**` to write, `**query**` to read. Customers can layer their own granular permissions on top. | | Shareable read-only deep-links (capability tokens) | — | partial | Send a regulator a single URL for one specific batch — no full account access granted. Short-lived, scoped to one endpoint and one HTTP method. | | **Wallet-agnostic Verifiable Credentials via OID4VC** | — | partial | Each Keycloak realm is a Verifiable Credential Issuer through Keycloak's native OID4VCI / OID4VP / SIOPv2 implementation. Credentials in `**sd-jwt-vc**` (selective disclosure first), `**jwt_vc_json**`, `**ldp_vc**` and ISO mDoc — the holder picks the format. Interoperable with every OID4VC-compliant wallet already in production or in pilot (EU Digital Identity Wallet, Catena-X Managed Identity Wallet, enterprise business wallets, sector wallets). No wallet lock-in. | | Globally-scoped issuer trust list | — | partial | Verifiers need to know which issuers are trustworthy. OpenEPCIS expects to maintain an open, globally-scoped trust list — not EU-only or sector-only. The trust-list surface and population pipeline are the work in flight. | | EPCIS event → VC issuance pipeline | — | partial | The protocol layer (Keycloak OID4VCI / OID4VP) ships today. The named credential schemas (`**EPCISCommissioningCredential**`, `**DPPBatteryPassportCredential**`, `**EUDRDueDiligenceCredential**`, `**UNTPDigitalConformityCredential**`) and the bridge from capture/save into VC issuance are the named [roadmap](https://openepcis.io/docs/platform-overview/roadmap) item. | | UNTP Digital Conformity Credential compatibility | — | partial | UNTP DCC is exactly the kind of VC the OID4VCI layer issues. Schema and field mapping to be published alongside the named credential pipeline. | | Verifier reference UI / SDK | — | partial | The OID4VP verification endpoint is live; a reference verifier UI for partners (browser-side and integrator SDK) is in flight. | | Row-level scoping below tenant (GLN / EPC / biz-loc) | — | roadmap | Today access is binary per tenant. Adding GLN-, EPC-range-, or biz-location-bound visibility (so a user sees only "their" sites) builds on the same DLS mechanism. | ## Testdata & Developer Tooling | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | Test event generation (REST + UI + bulk) | ✓ | ✓ | Synthesise realistic supply chains end-to-end — single events for demos, programmatic feeds for integration tests, or millions of events for performance work. | | Re-capture / replay tool | — | ✓ | Read events from one deployment, re-capture them into another (or the same one). Useful for environment cloning, regression scenarios, and reproducing production issues in a dev environment. | | Reference event collection (XML + JSON-LD) | ✓ | ✓ | Curated examples of every EPCIS 2.0 event shape, biz-step, and disposition — in both XML and JSON-LD. Used to test validators and onboard integrators. | | EPCIS REST conformance test suite | ✓ | ✓ | Point it at any EPCIS 2.0 endpoint — yours or anyone else's — and get a conformance report. The standards-compliance test set, open source; the Business edition extends it with platform-specific checks (multi-tenant DLS, capability tokens, the auto-derived linkset pipeline). | | Client SDK examples (multi-language) | ✓ | ✓ | Java, Python, Node.js, Go — example calls against `**/capture**` and `**/query**` to bootstrap an integration. | ## Platform & Operations | **Capability** | **OSS** | **Business** | **Notes** |
| --- | --- | --- | --- | | Self-host on Kubernetes (Terraform / Helm) | — | ✓ | Reference Terraform modules + Helm charts for production deployment — opinionated but not vendor-locked. | | Self-host on Docker Compose | — | ✓ | Ansible-driven Docker Compose stack — the fast path for smaller deployments and local development. | | OpenTelemetry tracing | — | ✓ | End-to-end traces across REST endpoints, capture pipeline, and storage — drop into whatever observability stack the customer already runs (Grafana, Jaeger, Honeycomb, …). | --- > This matrix lists what's available today. The [roadmap](https://openepcis.io/docs/platform-overview/roadmap) lists the strategic next steps — Verifiable Credentials for EPCIS events, the event-to-resolver masterdata bridge, sub-tenant scoping, and a retrieval corpus for the AI assistant.