Connections — bringing a brand's own data in

A Connection is a read-only link from a system a brand already runs into their DPP Agent tenant. The brand's PIM knows the composition, the webshop knows the GTIN and the photography, the compliance platform holds the declaration of conformity. A passport needs all of it, and none of it should have to be typed twice.

Nothing about a Connection is a data-sharing arrangement between DPP Agent and the vendor of that system. The credential belongs to the customer, the data belongs to the customer, and the customer decides what we may read.

How it works

1. The customer creates a credential in their own system. An API key, an OAuth client, a service account — whatever that system issues. Scoped to their account, and to reading.
2. They paste it into DPP Agent under Data → Integrations, pick the provider, and save.
3. We read on a schedule, map the fields they have chosen, and write passports in their tenant. Nothing is written back to the source system.
4. They revoke it in their own system whenever they want. The next run stops. No request to us, no ticket, no waiting.

We never ask for a person's login to another system, and we do not ask a vendor to hand us anything about their customers. If a brand is on both platforms, the brand is the one who connects them.

What we read, and what we never write

Every adapter is read-only. No write scopes are requested, no schema changes are made in the source, and the mapping from source field to passport field is explicit and set by the customer rather than inferred by us.

Read scope is deliberately narrow. A PIM connection asks for a specific channel, locale and attribute allowlist rather than the catalogue; the result is that what leaves the source system is the handful of fields a passport actually needs.

How credentials are held

Connection credentials are encrypted before they are stored, with AES-256-GCM and a fresh random IV per record; the master key lives in the hosting platform's encrypted environment store and never in the database. The admin UI shows a redacted fingerprint after saving — rotating means pasting a new value over the old, not reading the old one back. Plaintext is decrypted in memory for the duration of a sync run and is not held between runs.

Available connections

Sixteen adapters ship today. Five have a written guide; the rest are configured the same way, from the same screen.

Product data

Evidence and traceability

When there is no adapter for the system

The Akeneo guide is the most detailed of the five written ones and the one to read first if you are reviewing this for an IT or security function. It covers authentication, scope limitation, what we store and what we never touch, in the form that review usually asks for.

Custom REST is worth knowing about before asking for a new adapter. Any catalogue API that returns JSON can be wired up from the settings screen — request shape, pagination style, and a dot-path to each field — which is usually faster than waiting for us to write a named one.

When the source has no API at all

Some systems have no API, or none a customer can get a key for. Then the route is a file: the bulk importer takes .xlsx, .xls or .csv, shows you every column it found, and lets you map each one to a passport field. GTIN is the only required column.

This is the right answer for a trial, a one-off catalogue, or a first load while a real connection is being arranged. It is the wrong answer as a permanent arrangement, for the obvious reason: a file is true on the day it was exported and drifts from then on, while a connection re-reads.

What this is not

It is not a marketplace app that a vendor installs and configures on a brand's behalf. It is not a bulk transfer between two companies. And it does not put us between a brand and their vendor: revoke the credential and the link is gone, with the passports already published unaffected.