Map supplier data into Pimcore. No code.
Pimcore 11 has no REST webservice, so SDM Portal writes through the Datahub GraphQL API: objects found by key, created under the folder you choose, updated one language at a time. The connector is in beta and this page says exactly what it does and does not do.
Connection
- ProtocolDatahub GraphQL, /pimcore-graphql-webservices/{config}
- AuthDatahub API key on the config's security definition
- VersionPimcore 11
- StructureClass
- AddressingObject key, under a target folder per profile
- StatusBeta
Where a Pimcore supplier feed actually gets stuck
Supplier files are built for humans. Pimcore is built for a schema. Most of the work is the distance between the two, and it comes back with every new file.
No REST webservice
Pimcore 11 dropped it. Everything runs through a Datahub configuration you create yourself, which decides which classes are readable and writable and holds the API key.
Objects are keys and paths
A Pimcore object is not addressed by an identifier attribute but by a key inside a folder tree. A supplier row has to resolve to a key before anything can be written.
Languages are separate writes
Localized fields are updated per language, which means a wide multi-language catalog is many small mutations rather than one document.
How SDM Portal writes into Pimcore
You draw the mapping on a canvas. Tricky rules are described in plain language and compiled once into a fixed rule, so runs stay reproducible. Below is what the Pimcore side of that actually does.
Datahub as the integration surface
You create a Datahub configuration in Pimcore, expose the classes you want to fill, set an API key on the security definition and activate it. SDM Portal connects to that endpoint with the key. Nothing is installed inside Pimcore.
Class-scoped mapping
Pick the class and the attribute rail scopes to its fields, the same way a family or a template does on the other two PIMs.
Existence swept by key
Before writing, SDM Portal looks up the keys it is about to touch and decides per row whether that is a create or an update. The sweep finds unpublished objects too, so an object you created in an earlier run is updated instead of duplicated.
A target folder you pick
New objects are created under a folder path set per profile. When the Datahub configuration exposes object folders, you pick it from a searchable tree read live from Pimcore; when it does not, you type the path.
Values written per language
One create, then one update mutation per language, paced so a large catalog does not flood the endpoint. An update with nothing in it is skipped rather than sent.
The same everything before the write
Upload, share link or email intake, the visual flow editor, AI-compiled transforms, the Translate and Compose blocks, the row-by-row dry-run, the approval workflow, create, update and upsert modes, and delta sync are identical to the Ergonode and Akeneo paths. Only the write differs.
What we can write into Pimcore
Values are written through Datahub update mutations per language. Select values map to the codes your class expects; SDM Portal does not create new values or fields in the class definition.
What the Pimcore connector does not do yet
We would rather you read this before you sign up than find it in week two. Every item below is a real boundary of the Pimcore connector today.
Younger than the other two connectors
It writes to a real Pimcore instance today: it finds objects by key, creates them under a target folder and updates values per language. It has fewer features than the Ergonode and Akeneo connectors, and they are all listed here.
Objects land unpublished
An object created by SDM Portal is not published. Publishing stays a Pimcore decision. The key sweep does find unpublished objects, so the next run updates that object rather than creating a second one.
Variants, option creation, workflow status
No variant parents and axes, no creating select values or options, no option enrichment and no workflow status transitions. Those are Ergonode and Akeneo features.
Creating fields
You cannot create a new class field from the editor. The class definition is managed in Pimcore.
Duplicate keys across folders
The key sweep matches across all folders. If the same key exists twice you get a duplicate-key warning and the write targets the first match.
One update per language per object
A wide multi-language catalog paces slower than the batched Ergonode and Akeneo write paths, where many products travel in one request.
The folder picker
Reading object folders is off by default in a Datahub configuration. Enable it to get the folder tree, or type the target path instead.
Questions about Pimcore and SDM Portal
Which Pimcore version and API does SDM Portal use?
Pimcore 11 through the Datahub GraphQL API. Pimcore 11 has no REST webservice, so Datahub is the integration surface. You create a Datahub configuration, expose the classes you want to fill, set an API key on its security definition and activate it.
What does beta mean for the Pimcore connector?
It writes to a real Pimcore instance today: it finds objects by key, creates them under a target folder and updates values per language. It is younger than the Ergonode and Akeneo connectors and has fewer features, which are listed on this page. We call it beta so you can judge that for yourself.
Are the objects published automatically?
No. Objects created by SDM Portal land unpublished, and publishing stays a decision in Pimcore. The existence sweep does find unpublished objects, so a later run updates the object you created rather than making another one.
How are Pimcore objects matched to supplier rows?
By object key. Before writing, SDM Portal sweeps the keys it is about to touch and decides per row whether that is a create or an update. The sweep matches keys across all folders, so if the same key exists twice you get a duplicate-key warning and the write targets the first match.
Can I still use the visual editor and the dry-run?
Yes. Everything before the write is the same as for Ergonode and Akeneo: the flow canvas, transforms, AI-compiled rules, the Translate and Compose blocks, the row-by-row dry-run, the approval workflow and delta sync.
Running a different PIM?
The editor, the transforms and the workflow are shared. Only the write path differs per PIM, so each connector has its own page.
Map Pimcore once. It runs itself.
Start a workspace, connect your Pimcore instance and map your first supplier file. Fourteen days free, no card charged during the trial.