Connectors and integrations

DAM, PIM and CMS connectors and middleware: what to decide first

This page gathers the integration work I have carried out between DAM, PIM and CMS platforms — Bynder, Akeneo, inRiver, Frontify, Drupal — and states what each one actually produced: a middleware, a connector, a study, a scoping exercise. It sets out the reasoning and the failure modes, never a client’s code or configuration.

The case studies tell a story: the context, the constraint, the outcome at one client. This page works the other way round. It starts from the decision you face before committing — which matching keys actually exist in your data, where a native connector stops and a custom build starts — and links through to the engagement behind each answer.

Bynder
Akeneo
inRiver
Frontify
Drupal
API REST
Docker
Python

Vendor documentation describes precisely what a connector does once installed. This page covers the step before that: what has to be measured in your own data and tested against your own APIs to know which one to install, and what will still need building.

The chain is always the same; what changes from one project to the next is what each step has to guarantee.

Bynder → Elementor

WordPress plugin

Bynder
Elementor
WordPress

The Bynder DAM inside the Elementor editor

Dropping a DAM URL into an Elementor widget costs the visual its srcset and its dimensions, and detaches its alt text from the media repository — because WordPress indexes media by identifier, never by URL. This plugin keeps the identifier all the way to render.

The Bynder connector for Elementor

Five integration engagements, and what each one produced

What follows is consulting work: integration engagements delivered for clients, not products.

Five integration engagements, each labelled for what it actually is: one middleware, two connectors, one feasibility study, one scoping exercise. Every card links through to the case study behind it.

Bynder ⇄ inRiver

middleware delivered

Industrial equipment manufacturer

Bynder
inRiver
Docker
Node.js
API REST

Middleware to change DAM without regressing the PIM feed

Replacing the DAM broke the chain that automatically fed assets and metadata into the PIM, across two entirely decoupled instances. I delivered containerized middleware: collection, filtering, fan-out to both instances, and mapping administration left in the hands of the business teams.

Mapping store, not shared identifier
Two separately administered platforms share no identifier, so the link has to live somewhere else and be maintained as an object in its own right.
Synchronization loops are structural
As soon as a write on one side triggers a read on the other, the chain can call itself back: the safeguard is designed upfront, not after the incident.
Zero regression, a verifiable criterion
Same collection scope, same asset-to-entity links, same rendering, no metadata lost: the criterion is set before the cutover, not argued about after it.

Read the case study

PIM → Frontify

connector delivered

Specialist retail chain

Frontify
PIM
Python
API REST

Keeping DAM assets aligned with the product repository

Product visuals and documents sat on one side in the DAM, on the other in PIM exports, with no automatic link and nothing keeping the two aligned over time. I delivered a standalone connector that reconciles both repositories, enriches the metadata and logs every decision.

Replay a full cycle without writing
Bulk enrichment is judged on what it would have done: until a full cycle can be replayed dry, you do not know what you are about to overwrite.
An audit trail the business reads
A synchronization only the technical team can audit is never audited: the trail has to open in a spreadsheet, with no server log access required.
Delisted products decide the alignment
Alignment is not decided by new assets: updated media and delisted products are what determine whether the DAM still tells the truth.

Read the case study

DAM ⇄ CMS

custom connector delivered

Diptyque

DAM
CMS
API REST

A DAM ⇄ CMS connector, from specification to implementation

An engagement carried end to end on a connector between the DAM and the CMS, with authoring comfort and long-term maintainability treated as requirements.

Named engagement: the technical detail is not published, absent written agreement on a named case study.

Read the case study

Akeneo ⇄ Bynder

feasibility study and specification

Luxury fashion house

Akeneo
Bynder
API REST

Can your data even support asset-to-product matching?

A luxury house wanted every DAM file tied automatically to its product segmentation, yet no project document specified the flow meant to feed it. I settled the question on real data from both platforms, then delivered a feasibility report and an interface specification.

I have installed none of the third-party connectors sold for this pair: the question addressed here comes before that choice.

One key is never enough
DAM and PIM identifiers never cover the same scope: matching is built as a cascade, each level catching what the one before it leaves behind.
Measure overlap before costing anything
Overlap between candidate identifiers is measured on real data: it is what decides whether the flow is feasible, and not merely desirable.
Probe the API rather than read it
Pagination, throughput, bulk update behaviour: these constraints are observed on the platform before they ever enter an interface specification.

Read the case study

Bynder → Drupal

scoping and costing

European industrial group

Bynder
Drupal
SFTP
Python

Where the standard module stops and scoping starts

The group’s country sites, running on Drupal, had to be fed from the DAM instead of through manual uploads. I scoped the connector: publication rules, metadata mapping onto CMS fields, and a costed technical dossier handed to the client for its decision.

Publication rules come first
What reaches the websites is not everything the DAM holds: the rule that decides is settled with the business before it is written into the connector.
The CMS constrains the mapping
Rich metadata is only worth something if a field exists to receive it on the CMS side: the mapping is designed from the downstream end, never upstream.
Costing before building
Scoping ends in a decision: what the standard module covers, what remains to be written, and what each option actually costs the client.

Read the case study

How connectors break, and what answers each failure

A synchronization between platforms does not fail at random: it gives way at the same points, whatever the tools involved. Here are six structural failure modes met on real engagements, and the principle I set against each.

Matching built on a single key

Tying a media file to a product on a single identifier holds on the sample and breaks on the rest: the two repositories share neither scope nor granularity.

The principleCandidate keys are tested against real data, their overlap measured, then ordered as a cascade running from the most reliable to the most forgiving.

When each write triggers another

As soon as a flow runs both ways, an update written on one side is read back as a change on the other, and the chain starts feeding itself.

The principleA connector has to tell a genuine business change from the echo of its own write; without that distinction, no amount of scheduling tuning will contain it.

Reading everything on every run

A connector that rereads both repositories in full on every run works while the catalogue is small, then meets the rate limits of the APIs it depends on.

The principleOnly what changed since the previous pass is processed; the cost does not vanish, it moves to defining rigorously what counts as a change in the first place.

The product that leaves the catalogue

Most synchronizations know how to create and update, yet nothing states what becomes of an asset whose product has left the source repository.

The principleRemoval semantics are settled before any development: unpublishing, reclassifying or doing nothing are three business decisions, never a default branch.

Writing before you have looked

A mapping that looks correct on three examples can produce wrong values at scale in a single run, and a bulk write is not something anyone rereads by hand.

The principleEvery cycle must be replayable in full without writing anything, so the decision to update rests on an observed outcome rather than on an intention.

A discrepancy nobody can investigate

When a wrong value lands in the DAM, nobody can say which decision produced it: business teams have no access to server logs, and debate replaces investigation.

The principleEvery run leaves a decision-by-decision trail in a format the business teams open on their own, without going through operations or back through the supplier.

What to settle before costing a connector

A connector is not costed from an architecture diagram: it is costed from four decisions that can be settled before a single line of code is written. Below is the order I work through them, and the measurement protocol you can hold any provider to.

Measure matching on real data

Can our assets be tied to our products automatically?

This is where the question that governs everything else gets settled: is automatic matching possible at all, and on which identifier? You measure it by comparing the candidate identifiers held on both platforms and recording an overlap rate for each, across the full scope rather than a demo sample.

Settle the matching model

What happens when one key is not enough?

Here you settle the cascade of matching keys, the direction of the sync, which side wins a conflict, and what becomes of delisted products. It is written up as a documented matching rule, validated on a control batch before the first write, with cardinalities recorded from the data rather than from the declared schema.

Probe the API before committing

Will the volumes fit the window we have?

You decide whether the flow holds at the intended cadence, and what the fallback is when it does not. This is established on a bounded, read-only batch: pagination, rate limits, bulk update behaviour and failure modes are observed on the platform before any effort is committed.

Plan for operations and proof

Who stays in control once the connector ships?

You decide who administers the mapping over time, what gets logged, and how a cycle is shown to be correct without opening server logs. Acceptance is where you check it: a dry-run mode that replays a cycle without writing, a log the business can open in a spreadsheet, a rollback snapshot before any bulk update.

The questions to ask, mine included

This list is meant to be put to any provider. A missing answer is not a methodological detail: it means the estimate rests on an assumption.

Ask for the identifier overlap rate measured across the whole scope, not on a demo sample.
Require a written key cascade: what exactly happens when the first key returns nothing?
Were the metaproperty cardinalities recorded from the data, or copied from the declared schema?
Have the stated API constraints been tested on a real batch, or read in the documentation?
Insist on a dry-run mode: a full cycle must replay without writing anything.
Is a rollback snapshot taken before the first bulk write?
Ask to see a run log: your business teams must be able to read it without server access.

A data migration is not an interconnection

In my engagements, SFTP, SharePoint, Box, WordPress and S3 buckets are migration sources, never continuously connected targets. Conflating the two families distorts the estimate from the first meeting onwards.

See the DAM migrations See all services

Common questions about connectors and synchronization

Native connector or custom build: how do you decide?

A vendor-published connector covers a standard use case, its author maintains it, and it is almost always the first option to assess. The useful question is not how good it is but how far it reaches: does it cover the direction of flow, the object types, the cardinalities and the publishing rules you actually need? A custom build earns its place when the answer is no on something structural, or when two decoupled instances require a reconciliation the catalogue does not anticipate. So I start by reading the official documentation and holding its scope against yours.

How do I know whether my data can actually link an asset to a product?

You measure it, you do not assume it. List the candidate identifiers on both sides — product reference, supplier code, a fragment of the file name — then measure, on the real data, how far each one actually overlaps, along with the effective cardinality of the links: one visual against several products, one product against several visuals. A single key is rarely enough; what holds up is a cascade of keys, each level measured and documented. Until that work is done, any connector estimate is an intuition.

What is a middleware, and when is it better than a point-to-point link?

A point-to-point link joins two platforms directly, which is the sensible choice when there is one source, one target and one direction of travel. A middleware is an intermediate layer that collects, filters, distributes and holds the correspondence between the objects on either side. It earns its keep once the two systems share no common identifier, once several instances have to be fed, or once you want a single logged control point instead of logic scattered across both platforms. The cost is real: one more component to host, watch and document.

What happens to the connector when one of the two platforms changes?

This is the normal case, not the exception: an API version moves on, a data model is reworked, a DAM or a PIM is replaced. What protects you is not the code but the separation between the mapping and the machinery: when the correspondences live in a declarative layer, changing one end means rewriting a table rather than a connector. The criterion to set at scoping time is no regression: the same collection scope, the same links between objects, no metadata lost, verified before and after the cutover.

Who keeps control of the mapping once the connector is delivered?

The mapping is a business decision, not a technical detail: it states which field of the product repository feeds which media metadata. It therefore has to stay administrable without touching code, and without depending on whoever wrote it being available. In practice that means an interface or a format the teams can handle, a record of what was changed, and the ability to replay a full cycle in dry-run mode before anything is written. A connector whose mapping only its developer can edit creates a dependency nobody wants.

What does maintaining a synchronization really cost?

I will not quote a range: it depends on the number of flows, their frequency, the volumes and how stable both platforms are. The cost lines, however, are always the same and can be listed at scoping time: monitoring runs and rejects, revising the mapping when the catalogue moves, adapting to API versions, and handling the edge cases — a delisted product, a replaced asset, a duplicate. The most underestimated line is not the technical fix, it is the human time spent arbitrating discrepancies.

Is a migration from SharePoint or SFTP the same thing as an interconnection?

No, and conflating the two shows up in the estimate. A migration is one-way and finite: you map the source, rebuild the taxonomy from the folder tree, deduplicate by archiving rather than deleting, reconcile field by field, and then it ends. An interconnection is a living flow: a correspondence maintained between two repositories, updates and withdrawals to handle, monitoring over time. The first is accepted once; the second is watched for as long as it runs.

Every engagement described here corresponds to real work, labelled for what it produced. If your own pair of platforms is not on this page, the work starts the same way: measure, on your real data, what can be matched automatically, then cost what remains to be built.

An integration to scope?

Tell me which platforms are involved, the volumes and the deadline you are working to: I will tell you what needs measuring first and what a defensible estimate depends on.

Get in touch