Project visuals
Interface screenshots, reconstructed deliverable extracts and workflow illustrations are labelled. All visuals use fictional content and metadata, with client branding removed. Select an image to view it full size.
The engagement
An international industrial supplier's DAM was migrating from a legacy platform to Bynder. That cutover broke the chain automatically feeding assets and metadata into the inRiver PIM, across two entirely decoupled instances. The success criterion was set upfront: zero regression at cutover: same collection scope, same asset-to-entity links, same rendering, no metadata loss.
We designed and delivered containerized middleware: collection, filtering, fan-out to both instances, a composite-key mapping store, delta polling and safeguards against synchronization loops. Mapping administration runs through a web interface, backed by a spreadsheet ⇄ JSON tooling chain so business teams stay in control without touching code.
It ships with a read-only diagnostic CLI and a documented cutover scenario. The client retains ownership of its mapping and has a single control point between DAM and PIM.
Takeaway
A takeaway for your project
We gave the teams a control point between DAM and PIM, with manageable mapping and a documented cutover scenario.
Technologies
- Bynder
- inRiver
- Docker
- Node.js
- API REST
This engagement is one of the integrations documented on our dedicated page. We present delivered work, feasibility studies and scoping engagements, with the checks to make before development.
What to settle before committing to an integrationYour next step
Does a DAM change put your PIM workflows in question?
Describe the platforms, instances to feed and exchanges to preserve. We can scope the middleware, mapping ownership and acceptance criteria for your cutover.
Discuss your project