Contentful DAM integration

What a Contentful DAM integration must do

A Contentful DAM integration must give editors approved assets in the entry editor and keep every reference valid until the asset is withdrawn.

Contentful is a headless CMS: it stores structured content and delivers it through APIs. The DAM vs CMS guide explains why a CMS asset library makes a weak DAM. The DAM integrations guide places the CMS among the other DAM connections.

How Contentful models assets

Contentful models assets as their own content type: a file plus metadata, linked from entries and published separately.

• Fact: an asset holds files such as images, videos, audio or PDFs, usually attached to entries with links.
• Fact: creating an asset takes three steps through the Content Management API: create, process and publish.
• Fact: assets can be localised with a separate file for each locale.
• Fact: published images are served from images.ctfassets.net, and EU data residency customers use images.eu.ctfassets.net.
• Fact: the Images and Assets APIs serve published assets publicly, without a token.

The Images API makes Contentful its own delivery layer. A DAM that copies files into Contentful gets resizing, cropping and format conversion through URL parameters. A DAM that keeps files outside Contentful delivers through its own image CDN.

How the App Framework connects a DAM

The Contentful App Framework connects a DAM through frontend apps in the editor and backend apps that act on events.

Fact: Contentful Marketplace publishing is open to a select group of technology and integration partners. A DAM app outside the Marketplace installs as a custom app, which the buyer's team or the vendor hosts.

Integration patterns for Contentful

Contentful DAM integrations follow three patterns, and each pattern sets who stores the file and who serves it.

DAMSelection assessment: the reference pattern fits most organisations with a mature DAM, because rights and versions stay in one system. The copy pattern fits teams that want Contentful's Images API for all web images. The headless DAM guide covers the delivery architecture behind both.

Worked example: a migration copies 40,000 images into Contentful. Each asset needs three calls: create, process and publish. At 10 calls per second, 120,000 calls take at least 12,000 seconds, about 3.3 hours, before retries.

What must stay in sync with Contentful

Five changes in the DAM must reach Contentful within a stated time: new versions, rights expiry, deletions, metadata and alt text per locale.

Fact: archiving or deleting a Contentful asset removes its files from the CDN, but files may remain reachable for up to 48 hours. A rights expiry handled through the copy pattern must start at least 48 hours before the end date. Usage rights records in the DAM need that lead time as a field.

Fact: Contentful sends a save webhook when an entry or asset changes through the Content Management API or an app. Fact: failed webhooks retry up to two more times, about 30 seconds apart, and a timed-out request is not retried. The DAM vendor needs a reconciliation job for missed events.

Alt text belongs in the DAM per language. The accessibility and alt text guide covers that source model. Contentful's per-locale fields can hold each language, so the connector maps DAM languages to Contentful locales.

The four depth levels for Contentful

DAMSelection rates Contentful integration depth on the same four levels as every other platform, based on who builds and maintains the connector.

Vendor ratings appear on vendor profiles once verified. The integrations overview explains the scale for all platforms.

What to test in a Contentful demo

A Contentful demo tests the asset loop in a sandbox space with the buyer's own content model, locales and assets. Add these steps to the scripted demo.

1. Install the DAM app and show which app locations it uses.
2. Open an entry and pick an approved image from the DAM with three facets.
3. Show what the field stores: asset ID, URL, metadata or a Contentful asset link.
4. Pick a DAM master above 4,000 pixels and show the delivered rendition size.
5. Show alt text in two locales on the delivered asset.
6. Replace the image with a new version in the DAM and show the website result.
7. Expire the rights on the image and show the entries the app flags.
8. Delete an asset in the DAM and show the result in Contentful.
9. Show the DAM usage report listing the entries that use the asset.
10. Try to pick an asset outside the editor's DAM role and show the block.

The Demo Script Generator formats the steps as a scenario. The panel scores each step pass or fail against criteria written before the demo.

Common failure points

Contentful DAM integrations fail at five points that a buyer checks before signature.

• Stale copies: copied assets keep old files and metadata when the sync covers only new assets.
• CDN lag: archived or deleted files may stay reachable for up to 48 hours.
• Missed events: three webhook attempts over one minute leave gaps without a reconciliation job.
• Locale gaps: alt text in the DAM covers fewer languages than the Contentful locales.
• Hosting ownership: a custom app hosted by the buyer needs an owner, monitoring and updates.

Questions for the DAM vendor

The buyer sends these questions in writing and asks for documentation with each answer.

1. Which pattern does the Contentful app use: copy, field reference or native external references.
2. Is the app listed on the Contentful Marketplace, and who hosts and supports it.
3. Which app locations does the app use, and which permissions does it request.
4. How does the app refresh stored metadata, and how often.
5. How does the app handle rights expiry and deletion in entries that use the asset.
6. How does the app map DAM languages to Contentful locales for alt text.
7. Which Contentful plan does the pattern require.