--- title: "GS1 Germany Sync" description: "Publishing your catalog to GS1 Germany — service tokens, licensed prefixes, the key pool, Verified by GS1, and the per-record Sync tab." canonical_url: "https://openepcis.io/docs/digital-data-management/gs1-sync" last_updated: "2026-08-26T20:11:05.654Z" --- ## Why publish to GS1 at all Your passports live on your own resolver — but retailers, marketplaces and data pools do not come to your resolver to learn about your products. They ask the **GS1 network**, where master data is exchanged between trading partners. Outbound sync closes that gap: records curated in DDM are published to external channels, the first of which is the **GS1 Germany Service Platform**. Curate once, publish everywhere — the same single-source principle that drives the rest of DDM, extended beyond your own infrastructure. Because publishing under a GS1 identifier is a licensed act — only the licensee of a company prefix may publish data under it — the machinery involves credentials and identifier management, not just a "send" button. Three pieces work together: a **service token** that proves your license, the **key pool** that manages the identifiers you draw from your prefixes, and the per-record **Sync tab** where publication actually happens. ## The GS1 Germany service token On [Profile](/docs/digital-data-management/getting-started#your-profile), deposit the access token GS1 Germany issued to you. DDM validates it against GS1 before storing it, and in the same step discovers the **company prefixes the token covers** — those prefixes are from then on what authorizes outbound publishing for your tenant. You never configure prefixes by hand; the license itself is the source of truth. The token is stored encrypted and never displayed again — only a masked form (`****1234`) remains visible. **Re-validate** re-checks it against GS1 at any time, which is how you notice a token that was rotated or revoked on the GS1 side before a failed sync tells you. ![The GS1 Germany cards on the profile page | Figure 1: The deposited service tokens with their licensed prefixes, and the key pool below](/img/13.Digital-Data-Management/profile-gs1.png) A licensee may hold several tokens — for different group companies, or different prefix ranges. Deposit each with a label to tell them apart; **which token publishes a given record is decided by the record's prefix**, never by an ordering, so there is no "primary" token to get wrong. Removing a token stops publishing under its prefixes immediately and leaves the others untouched. ## The GS1 Company Prefix Pool A GS1 company prefix is a finite resource: it yields a limited range of GTINs, and a number, once burned, is gone. The **key pool** card on the Profile page exists so numbers do not leak away in everyday work. When someone [creates a product](/docs/digital-data-management/product-catalog#creating-a-product) and presses **Draw**, the next free number from your prefix is *reserved* — held for that person, but not yet registered with GS1. Only saving the record registers it. The distinction is what saves the range: a key drawn for a form that was then abandoned does not quietly disappear — it stays in the pool as *Reserved*, visibly idle ("held for 6 days"), and **Hand back** makes it available again. A *Registered* key, on the other hand, is GS1's now; the pool marks it accordingly and will not offer it again. Alongside DDM's own ledger, each key also shows **GS1's own status** for it — *Reserved*, *Active* or *Inactive*, as reported by the GS1 registry — so the pool and GS1 can be compared at a glance. Where the deployment enables it, a registered key can be **activated** at GS1 directly from the pool. Activation cannot be undone, so a confirmation dialog stands in front of the button. **Find a key** answers the recurring audit question — "did we ever draw this GTIN?" — and the recent-activity list shows who drew and returned what. ## Verified by GS1 The counterpart to publishing carefully is creating carefully, and that check sits in the create flow itself: every new product's GTIN is verified against the GS1 registry, the licensee is shown inline (and can be adopted as brand owner in one click), and an unverified GTIN blocks creation. The details live in the [Products chapter](/docs/digital-data-management/product-catalog#the-gtin-and-why-ddm-is-strict-about-it); the point to remember here is that by the time a record reaches the Sync tab, its identifier is already known to be real. ## The Sync tab Publication happens per record, in the editor's **Sync** tab — one card per configured channel: ![The Sync tab of a product | Figure 2: The GS1 Germany channel card — state, timestamps, manual trigger and the attempt history](/img/13.Digital-Data-Management/editor-sync-tab.png) The card is built to answer, at a glance, the question every product manager eventually asks: *is this record out there, and is what's out there current?* The **state badge** answers it truthfully per channel — *Not synced*, *Pending*, *Syncing*, *Synced*, *Failed (retryable)*, *Failed*, or *Needs attention* — flanked by **last synced**, **last attempt** and the **trigger** (manual, or automatic on save). **Sync now** publishes on the spot, **Retry** re-runs a failed attempt, and **History** lists every attempt ever made, with outcome and timestamps — the audit trail for "when did GS1 last receive this". Just as important is what the card says when publishing is *not* possible. Instead of a failure after the fact, the trigger is disabled with the reason spelled out: the channel is switched off on this deployment; no credentials are deposited yet (with a pointer to the Profile page); or no deposited token licenses this record's prefix. Each message names the person who can fix it. A channel can run in **dry-run mode**: attempts are recorded with everything they *would* have sent, but nothing leaves the system. It is the rehearsal mode for a rollout — same records, same validation, zero risk to the live GS1 platform.