DAM integration: APIs, references and workflow patterns

A DAM integration needs a clear answer to two questions: which system owns the media, and does the destination need a reference or a file of its own? Those decisions determine what the integration must move, what it must keep current and who handles a failed update.

Consider a product page. Its photograph may belong in the DAM, its product facts in a PIM and its layout and publication state in a CMS. Connecting those systems should let each retain its responsibility. Making all three store and edit the same image record creates more synchronization work than the page necessarily needs.

API access, CDN delivery, native connectors and publishing integrations solve different parts of that problem. Choose the pattern around the destination's requirements before choosing the software that connects it.

Assign ownership before choosing a connector

Start with the source asset, then identify the owners of the decisions around it. Who maintains the original? Who supplies the product identifier? Who selects the photograph for this page? Who decides when the page goes live?

One possible division is:

• The DAM maintains the authoritative media asset and its identity.
• The PIM maintains product facts, including the SKU.
• The CMS maintains page structure, placement and page-specific content.
• A project or review system records the team's selection and review decisions.
• The publishing platform maintains publication state and scheduling.

This is an architectural example, not a mandatory allocation. Some organizations combine several responsibilities in one application. The useful rule is to name an authoritative owner for each object or field before allowing other systems to edit it.

Microsoft's guidance on distributed data makes a related distinction: one service can own an entity while others hold only the subset they need. Apply that principle to shared asset data rather than mirroring every record everywhere.

The DAM can remain the authoritative media source even when a CMS holds references or a publishing platform holds downstream copies. That does not make the DAM authoritative for product descriptions, approval decisions or publication state.

Decide whether the destination needs a reference or a copy

A reference-based integration leaves the media with its source system. A copy-based integration gives the destination its own binary. Both are valid; they create different operational responsibilities.

Keep a reference when the destination can use external media

A CMS might store an asset ID together with an output requirement. The frontend resolves that selection to a delivery URL and requests the image representation it needs. Alternatively, the CMS may store the delivery URL directly.

An asset ID identifies the library asset. A delivery URL identifies a requested output. A transformation recipe or preset describes how that output should be produced. Decide which of these the consuming application needs, rather than treating them as interchangeable strings.

In the product-page example, the CMS can refer to the authoritative photograph without importing another original into its media library. A defined image recipe can produce the technical output for the placement. This reduces binary duplication and gives editors a route back to the source.

The destination must support external media, and the reference must remain usable. Decide what happens if the source is removed, a different asset is selected or a shared preset changes. Keeping the same URL does not by itself establish when downstream caches will show a changed output. The separate guide to delivery URLs and CDN caching covers representation identity in more detail.

Export a copy when the destination requires an upload

Some platforms ingest media into their own storage and publish only those uploaded files. In that case, obtain the required representation from the DAM and transfer the binary to the destination.

The destination can then serve its copy without requesting that image from the DAM on each view. The cost is another stored file and a separate replacement process. Updating the source in the DAM does not automatically change the imported binary.

Retain a small provenance record: the source asset ID, the resolved output recipe or preset configuration used, the export date and the destination's file ID. Put that record somewhere the team can actually retrieve it, such as the destination record or an integration log. These are recommended integration records, not a claim that every DAM supplies those fields.

If the product photograph changes, someone must identify the affected copies, decide which should be replaced and perform those replacements. A copied file is a downstream artifact, not an automatically synchronized DAM representation.

Use an API, a connector or a manual handoff for the work required

The reference-or-copy decision describes what the destination retains. An API, connector or human handoff describes how the work happens. A custom API integration can select an asset reference; it can also export a copy. A native connector may do either, depending on its contract.

Use a DAM API integration when an application needs to interact with the library: upload a source, retrieve an asset record, search, update supported metadata or organize assets through documented collection operations. A custom internal admin could upload a photograph to Vyso, retain the returned asset identity and associate it with a product in its own database.

That requires application code and an appropriate authentication model. It does not establish a native integration with the calling application. The Vyso API workflow guide covers the request-level work separately.

For an occasional transfer, a person downloading a file and uploading it elsewhere may be sufficient. Record the source and output requirement alongside the handoff. A manual process with clear provenance can be preferable to maintaining an integration that runs only a few times a year.

Use this table to choose a starting pattern, then check the destination's actual capabilities:

Destination need	Starting pattern
Display a supported image on a website that accepts external media	Asset reference and CDN delivery
Browse or select library assets in a custom internal application	Developer API with an application-built selection interface
Upload assets or update supported metadata from a custom admin	Authenticated Developer API
Send media to a platform that requires its own uploaded binary	Export and copy, manually or through an integration
Browse DAM assets inside Figma or an Adobe application	A verified connector or custom extension for that tool
Schedule or publish campaign content	The publishing or automation system

A native connector, custom integration or middleware/iPaaS service is an implementation choice. None removes the need to define ownership, mapping and failure handling. Choose the simplest pattern that preserves the operational control the workflow needs.

Move only the data the consuming system needs

An integration does not have to transmit an entire asset record. Decide what crosses the boundary by asking what the destination must do with it.

• Asset ID: retain a relationship to the authoritative library asset.
• Source URL: retrieve the original when the workflow genuinely requires it, subject to the access model.
• Delivery URL: request a defined representation for display or import.
• Transformation recipe or preset: describe a reproducible technical output.
• Selected metadata: supply the context needed for selection, display or association.
• Binary file: satisfy a destination that must store its own copy.

A product page might need the image reference, its placement recipe and local alt text. It may have no reason to duplicate the DAM's generated captions, collection membership and processing details. Moving unused fields expands the mapping and update work without helping the page.

Also distinguish the source from the output: a thumbnail URL is not a replacement for the original's identity. If a downstream copy is retained, keep enough information to connect it to both the source and the representation that produced it.

Give each shared metadata field an owner

Metadata conflict often starts with an innocent convenience: the same value becomes editable in two interfaces. When those values differ, the integration has no way to know which one represents the organization's decision.

For the product-page example, the PIM could own the SKU while the DAM stores a searchable copy of that identifier in a supported metadata field. The CMS could own page-specific alt text because the appropriate description depends on the image's use in that page. The DAM could own a reusable descriptive caption. Those fields serve different purposes and should not overwrite one another merely because both contain text.

Write down the mapping, the authoritative owner and the allowed direction of updates. A downstream value copied from its owner is a projection: useful local data, but not another authority. If users need to correct it, decide whether the correction goes back to the owner or becomes a clearly separate local field.

Use the fields the product actually supports. Vyso's metadata reference documents user-managed titles, descriptions, captions and tags; this does not establish arbitrary custom metadata schemas. Nor should a collection name become an implied approval state or a permission boundary.

Review decisions can remain in the project's review record, linked to the selected asset. The integration needs that relationship, not an invented approval capability in the DAM.

Make bidirectional synchronization a deliberate choice

Prefer an authoritative owner feeding downstream references or selected metadata when that meets the requirement. Two-way synchronization needs additional rules because both sides can change data before the other has caught up.

Suppose the DAM caption and the CMS alt text are synchronized in both directions. An editor improves the alt text for a product page. The integration writes it over the reusable caption, then treats that change as another update to send back. The result can be a loop, a lost edit or a field that no longer means what either team intended.

If two-way editing is necessary, define which fields participate, how concurrent edits are resolved, how updates originating from the integration are recognized and how deletions are handled. Specify how failed operations are retried without duplicating work, and where an unresolved conflict is surfaced.

These are responsibilities of the integration you build. Do not assume a DAM API provides bidirectional synchronization, event notifications or conflict resolution unless those capabilities are explicitly documented. A working upload or metadata request proves only that operation.

Choose a CMS integration pattern that fits its content model

There are three common ways to integrate a DAM with a CMS.

A reference field stores the selected asset ID, delivery URL or preset reference. The frontend requests the media while the CMS continues to own the page. Check whether the CMS, its editor preview and the frontend support the same external-media pattern.

A custom asset picker lets editors browse or search the DAM inside a CMS field. A developer builds the selection interface against the DAM API, handles authentication and stores the chosen reference. Salesforce's CMS content selector documentation, for example, requires an external provider configuration and a custom selection component. Selecting an asset creates a CMS record with a reference to it. That is a CMS extension mechanism, not evidence that Vyso ships a Salesforce connector.

A binary import puts an exported representation into the CMS media library. If the CMS requires this pattern, retain its relationship to the DAM source and define how a replacement reaches existing content.

CMS integration is an architectural pattern, not proof of a native plugin. An API alone also does not create an in-app Figma, Photoshop or other Adobe experience. If designers need that workflow, verify an actual connector or extension, its supported operations and its behavior when assets change.

Keep asset selection and publishing in the consuming system

The application decides which source to use and which output to request. A regional site might select one asset for Poland and another for Germany through its own content model or business rules. Serving the selected image is separate from making that regional decision.

The same boundary applies to technical outputs. Supported resizing, cropping and explicit format conversion can produce a requested representation. They do not translate text in a design, reposition a product for a different composition or decide which creative suits a market. A localized design may require another source asset.

DAM delivery serves the requested media representation. A publishing system decides when and where content goes live. A usable CDN URL does not schedule a campaign, publish an email, activate an ad or replace media inside another platform's stored files. The media distribution guide explains preparation, delivery and publishing as separate responsibilities.

Design for the failures that happen between systems

Test the boundary when something changes or fails, not only when the first image loads.

• Broken reference: the destination points to an asset or output that no longer resolves. Define who checks affected uses and chooses a replacement or fallback.
• Stale copy: the source changes but an imported binary remains unchanged. Identify who owns replacement and which destinations need it.
• Lost provenance: an export survives without a source reference or output recipe. Retain the relationship before transferring the file.
• Metadata conflict: systems disagree about a shared value. Resolve it through the field's named owner rather than whichever update arrived last.
• Permission mismatch: a user can open the CMS but the integration cannot retrieve the DAM asset, or vice versa. Test both access models separately; access to one system does not grant access to the other.
• Transformation drift: two consumers use different crop, size or format rules for the same placement. Give that requirement an owner and a documented recipe.
• Ownership ambiguity: two systems both accept authoritative edits. Decide which one owns the value before adding more synchronization.

Record enough about a failed handoff to identify the source asset, destination record and attempted operation. Choose who responds and whether the workflow pauses, keeps an existing copy or uses a fallback. A connector cannot make those business decisions on its own.

Where Vyso fits in this architecture today

Vyso's current documentation describes two relevant surfaces: the Developer API at https://api.vyso.io/v1 for library management, and delivery/CDN at https://cdn.vyso.io for requested image representations.

The documented API scope includes multipart uploads, asset listing and retrieval, supported metadata updates, collection operations, search and transformation preset management. Management requests use a Clerk bearer token and are scoped to the authenticated workspace. These operations provide a basis for a custom selection or administration workflow; the calling application still owns its interface and downstream records.

For metadata mapping, the supported user fields include userTitle, userDescription, userCaption and userTags. Collections group workspace assets, with assignment through the asset update operation. Neither mechanism establishes approval status or cross-system access rules.

Vyso preserves the uploaded source and produces image representations through explicit transformation chains or saved presets. Documented output encoders include JPEG, PNG, WebP and AVIF. The consuming workflow specifies the supported operations and output requirement; this is not automatic channel selection or localization.

The delivery scope described here concerns supported images. Acceptance of a stored file does not establish preview, enrichment or transformation support for every media type.

These documented surfaces do not establish native CMS, creative-tool, PIM or marketing-automation connectors, a permission-management API, outbound asset-event webhooks or automatic synchronization of copied binaries. A custom integration must verify the deployment, authentication and destination behavior it relies on.

Before building, test the integration contract

Take one representative asset through the intended workflow and answer these questions before extending it to the library:

• Which system owns the source asset, and which owns its selection for this use?
• Who owns each shared metadata field, and which direction may updates travel?
• Does the destination need a reference or its own binary copy?
• Does external media work in both the destination's preview and its published output?
• If a copy is required, where are the source identity, output recipe and destination file ID retained?
• Does the integration only read the DAM, or may it upload and update records?
• Is a custom API workflow sufficient, or does the user need a verified native connector?
• Who owns transformation requirements and checks that the output is suitable?
• What happens if the source, selected asset or preset changes?
• What happens if the source is removed or a reference becomes unavailable?
• How are conflicting metadata edits handled, and is two-way synchronization necessary?
• What authentication and access model applies on each side?
• Which system owns final publication and scheduling?
• Who sees a failed operation, and how is it retried without creating another copy?

Verify a normal handoff, a changed source, a missing reference and a failed request. For each test, record what the destination retained, whether provenance survived and who had to act. Those answers establish the integration's operational contract.