SaaS, hosted in Germany
Multi-tenant platform on Hetzner, Falkenstein. We operate, update and back up; you configure. Tenant isolation at data level, daily snapshots, off-host backups.
How the gate works
Sources in. Clean, entitled data out.
PIM Gate is the control layer between the systems that hold product data and everyone who needs it. It reads from your PIM, ERP and other sources, applies four operations — validate, translate, entitle, audit — and delivers the result to portals, APIs and feeds. Your PIM keeps its role. PIM Gate gives it a front door.
VALIDATE · rules before releaseTRANSLATE · delta, TM, reviewENTITLE · who sees whatAUDIT · versions & log
02 · Sources
Read from what you already run. Change nothing there.
PIM Gate connects to your systems read-only by default. Each source keeps its role and its schedule; PIM Gate maps what it delivers into one canonical product schema so that everything downstream speaks one language.Most companies do not have one source of product data. They have a PIM for marketing content, an ERP for prices and logistics, a DAM or file share for images and documents, and suppliers who deliver in their own formats. PIM Gate treats each of them as a source with its own connector, its own schedule and its own mapping. Nothing is written back to a source unless you configure it explicitly — for example, reviewed translations returned as drafts.
- Per-source connectors. XML, REST pull and scheduled SFTP, each source on its own schedule.
- One canonical schema. Typed attributes with unit, locale and market flags — the shared vocabulary for every portal and channel.
- Multi-language, multi-market. Locale fallback chains (for example de-CH → de-DE) are resolved in the gate, not in each channel.
- Source stays the source. Your PIM remains the system of record. PIM Gate reads; write-back is opt-in.
| source | method | status_key |
|---|---|---|
| PIM — Viamedici, Akeneo, Pimcore, Stibo, Censhare | XML | LIVE |
| Any system with files or an API | XML · REST pull · scheduled SFTP | LIVE |
| ERP / SAPcustom connector available now; standard connectors SAP, Dynamics, Oracle on the roadmap | custom connector | ROADMAP |
| Supplier data | Supplier Portal (XLSX, BMEcat, API) | 2026 |
| CMS content — Ibexa DXP, Drupal | translation connectors | COMING SOON |
| CRM & DAM — Salesforce, HubSpot, Cloudinary | standard connectors | ROADMAP |
| Source → canonical mapping UI, per-attribute mapping | configuration UI | 2026 |
03 · The four verbs
Four operations every record passes through.
The gate is not a copy of your PIM. It is a set of operations applied between source and consumer, configured once and enforced every time data moves.
ValidateLIVE
Nothing incomplete passes the gate.Rules describe what a record must contain before a given consumer may see it: required attributes, valid units, a classification, the fields a channel's schema demands. A record that fails is not dropped silently and not published half-empty. It is held with a reason on field level — missing: country_of_origin — so the team that owns the data knows exactly what to fix, and the channel never sees the gap.
- Required fields per consumer, not one global rule set
- Units and value types checked against the canonical schema
- Classification checks (for example ETIM class present)
- Field-level reasons for every held record
- Completeness visible per product before publication
RULE SCOPE: TENANT · PORTAL · CHANNEL OUTCOME: PASSED · HELD · REJECTED
Translate2026
Only what changed, in your words, approved by your people.When a source text changes, PIM Gate detects which segments are new or different and sends only those. Existing translations are reused from your translation memory (TMX), approved terms are enforced from your termbase (TBX), and the remaining segments go to the engine you have chosen for that language — DeepL, OpenAI, Anthropic, Azure OpenAI or an EU or local model. A reviewer per language approves before anything is published. If your translators prefer their own tools, they receive a small XLIFF or XLSX delta package without duplicates and return it the same way.
- Delta detection on segment level
- TMX and TBX reuse across languages and channels
- Engine per language or market
- Review queue with approve / request change
- Export/import packages for external translators
FORMATS: TMX · TBX · XLIFF · XLSX LOCALES IN PRODUCTION: de-DE · de-CH · en-GB
Entitle2026
Every user sees their own shelves — nothing more.Entitlements define which slice of the catalog a user, a portal or an API token may see and what they may do with it. They are layered: tenant, portal, role, market, category — down to the single asset. For sales, scope can follow the commercial relationship: a rep sees their customers, a customer sees what their agreement covers. Filtering happens on the server for every query, whether it comes from a portal page, an export or the API.
- Layers: tenant → portal → role → market → category → asset
- Relationship-scoped sales access (rep → customer → agreement)
- Server-side filtering on every API response
- Catalog selections by hand or by rule, saved filter templates
- Roles and groups in an admin console
EXAMPLE: role=dealer · market=CH → 312 of 20,418 SKUs
AuditLIVE
Every change and every download leaves a trace.Every export is stored as a version. You can compare any two versions field by field, see what a channel received on a given day and roll back safely. User actions — invitations, approvals, downloads, role changes — are written to an append-only log that cannot be edited after the fact. That makes answers to "who had which data sheet, and when?" a query, not an investigation.
- Versioned exports with side-by-side compare
- Append-only audit log
- Audit log UI in the admin console
- Bulk downloads with audit trail
- Optional 10-year audit-log retention
LOG: APPEND-ONLY RETENTION: STANDARD · 10 YEARS OPTIONAL
Illustrative values
04 · Consumers
People get portals. Systems get APIs and feeds.
Everything downstream reads from the same governed layer. A portal page, a shop import and a wholesaler's BMEcat file show the same approved value — each filtered to what that consumer may see.
For people
- Customer PortalLIVEdealers, distributors, key accounts
- Supplier Portal2026suppliers submitting data
- Sales Portal2026internal and external sales
- Media PortalROADMAPagencies delivering assets
For systems
- Versioned REST API /v1LIVEper-tenant tokens, rate limiting, entitlement filtering
- WebhooksLIVEsigned, fired on change
- Pull, push and scheduled deliveryLIVEmixed per integration
- Delta endpointLIVE/v1/sync/diff?since= returns only changed fields
- GraphQL endpoint2026
- Open Data feeds, DPP records, BMEcat2026via data modules
- Published OpenAPI spec & docs2026at docs.pimgate.ai
GET /v1/sync/diff
// Only what changed since the last syncGET /v1/sync/diff?since=2026-09-23T02:00:00ZAuthorization: Bearer <tenant-token> → 200 OK · 212 fields · 38 products · deltaA shop polls every night and receives only the fields that changed.
en
05 · Tenants and portals
One tenant per company. As many doors as you need.
A tenant is your isolated space on the platform: your data, your users, your rules, your subdomain. Inside it you open portals — one per stakeholder group — each with its own branding, domain, languages, markets and catalog selection.Groups with several brands or country companies run one branded tenant per brand or country, each under its own domain, all fed from the same or different sources. Because every portal reads from the tenant's governed data, adding a portal is configuration, not a project: choose the audience, the catalog selection, the markets and languages, the branding — and invite users.
- Tenant — isolated data, users and configuration; own subdomain, custom domain and certificate included.2026
- Portal — a web application for one audience; branding and theming per portal.2026
- Catalog selection — manual or rule-based, with markets and languages per portal.LIVE
- Branded tenant — one per brand or country company, under its own domain.2026
Portal users are unlimited in every version.
06 · Before and after
From point-to-point to one gate.
Without a gate, every new channel means another export from every source, and every change in a source ripples into every export. With a gate, each system connects once.
Without a gate
- Each channel has its own export script, schedule and field list.
- A PIM change breaks exports you did not know existed.
- Customers receive whatever was in the last email.
- No one can say who received which version.
With PIM Gate
- Each source connects once; each consumer connects once.
- Mapping and rules live in one place and are versioned.
- Every consumer sees its entitled, current slice.
- Every delivery is versioned and every download logged.
Add a source without touching a channel. Add a channel without touching a source.
07 · Getting started
Live in days for the first portal.
PIM Gate runs next to your PIM, so there is no migration to finish first. A first portal typically goes live in days to weeks, depending on your sources and the rules you want enforced.
- 01
Connect
PIM Gate reads from your PIM or ERP via XML, API or scheduled SFTP. We map your attributes to the canonical schema and set the schedule per source. Your PIM stays untouched.
- 02
Scope
Decide who sees what: tenants, portals, roles, markets, categories, down to the asset. Define the rules a record must pass for each consumer.
- 03
Deliver
Open the portal under your domain and brand, issue API tokens for your shop or DXP, schedule feeds. Invite users — as many as you need.
- →
Operate
We run, update and back up the platform. Your team adjusts portals, rights and rules as the business changes.
Onboarding is a fixed-price package, from €5,000.
08 · Delta and versioning
Delta, not dumps. Every export versioned.
Consumers receive only what changed on field level — about 95% smaller payloads than full exports. And because every export is stored, you can see exactly what any channel received on any day.Full exports are simple until they aren't: nightly files that take hours, shops that re-import 20,000 products to change three prices, and no way to tell which version a partner is looking at. PIM Gate computes the difference between the last delivery and the current state per field and per consumer. Webhooks fire with the delta; pull consumers ask /v1/sync/diff?since= and get the same. Every export is kept as a version you can compare with any other and roll back to.
- Field-level delta for API, webhooks and scheduled feeds
- Versioned exports with side-by-side compare
- Safe rollback to a previous export
- Migration bridge: old and new PIM in parallel, switch per attribute group
Illustrative payload sizes
0
smaller payloads with field-level delta
0
versions comparable side by side
0
changes needed in your PIM
09 · Clear boundaries
What PIM Gate is not.
A gate is useful because it does one job. These are the jobs it deliberately leaves to the systems you already have.
NOT A PIM
It does not replace your PIM.
Product data is created, enriched and approved where it is today. PIM Gate reads it, governs its distribution and never becomes a second master. If you change PIMs, the gate stays.
NOT A SHOP
It does not sell.
PIM Gate feeds your shop, DXP and marketplaces with governed data through the API. Checkout, carts and payment stay in your commerce system. The coming Commerce layer adds prices, availability and documents — still in front of your shop, not instead of it.
NOT A DAM
It does not replace your DAM.
Images, documents and data sheets travel with the product and are delivered under entitlements. Asset creation, editing and brand libraries stay in your DAM.
NOT A PROJECT
It is not a one-off integration.
It is a SaaS platform we operate, update and back up. You configure portals, rights and rules — no servers, no custom code to maintain.
10 · Deployment
One codebase, three ways to run it.
Most customers use the multi-tenant SaaS hosted in Germany. For data-residency or regulatory requirements, the same platform runs in a Swiss data centre or as a dedicated deployment.
Swiss hosting
The same platform in a Swiss data centre, for companies whose data must stay in Switzerland.
Dedicated or on-prem
A dedicated deployment or an on-prem installation for regulated industries such as medtech, insurance or public institutions. Enterprise agreement.
Stage / test tenant
A separate tenant on the same platform for testing changes before they reach production. Bookable with a production subscription.
11 · Questions
Questions architects ask.
- Because PIM Gate needs one. Your PIM is where data is created and approved; PIM Gate is the layer that opens it to people and systems outside it — with rules, entitlements and an audit trail your PIM was not built to provide for external users.
- Not by default. It reads. Write-back is opt-in and scoped, for example returning reviewed translations as drafts.
- It's SaaS: we operate, update and back it up. Your team configures portals, rights and rules — no servers.
- The portals and channels stay. The migration bridge runs the old and new PIM in parallel; you switch attribute groups from old to new source and can roll back.
- Through the versioned REST API with per-tenant tokens, signed webhooks, or scheduled delivery. The delta endpoint returns only changed fields.
- Yes. Start with one portal or one module, for example translation, and add modules later at list price.
- A separate stage/test tenant on the same platform, bookable with a production subscription.
- OIDC/SAML is on the roadmap for higher versions. See the roadmap for current status.