Acquia DAM becomes the single source of truth only once downstream systems pull from it. This page records which systems consume approved assets, when each comes into scope, and the integration pattern each one implies — native connector, CDN URL or API. It also records the sources already serving assets today, and how those are migrated and eventually retired without interrupting what depends on them.
Eight consuming systems are known today, each with an owner and an indicative date. The three Drupal properties use the native Acquia DAM to Drupal connector, four systems have no native integration and need a connector or API integration built, and SFMC has a paid third-party subscription connector, with no native connector available.
| System | Owner | Timeline | Integration approach | Notes |
|---|---|---|---|---|
| padi.com + B2C and B2B blogsDrupal | Axelerant | Nov 2026 | Native Acquia DAM to Drupal connector | |
| scubadiving.comDrupal | Axelerant | Feb 2027 | Native Acquia DAM to Drupal connector | |
| club.padi.com, pro.padi.comDrupal | PADI Engineering | Feb 2027 | Native Acquia DAM to Drupal connector | pro.padi.com assets are served by Cloudinary. With this integration, pro.padi.com would fully consume assets from Acquia DAM, but Cloudinary is not retired as Store assets are served from it. |
| B2C StoreCommerceTools / Cloudinary | PADI Engineering | Feb 2027 | No native integration. Connector / API integration needed. | |
| B2B StoreBig Commerce | PADI Engineering | Feb / May 2027 | No native integration. Connector / API integration needed. | B2B Americas in Feb 2027, other global stores in May 2027. |
| TravelDjango | Axelerant | Feb 2027 | No native integration. Connector / API integration needed. | |
| Learning platformDomiKnow | PADI Engineering | Feb 2027 | No native integration. Connector / API integration needed. | |
| SFMCSalesforce | Fast Slow Motion | Feb 2027 | Paid third-party subscription connector exists. No native connector available. | Axelerant can step in to assist with this integration rather than having a third-party vendor subscription. |
Five systems need a custom integration between Acquia DAM and the consuming platform. For CommerceTools and Big Commerce the platform-side endpoints already exist; for Django, DomiKnow and SFMC they have to be created, with endpoint ownership settled only for Django. Axelerant owns building the integration itself in all five cases.
| System | Existing owner | Endpoints needed | Who owns creating the endpoints? | Who owns building the integration? |
|---|---|---|---|---|
| CommerceTools | PADI Engineering | Endpoints existPOST /oauth/token — authenticates the integration with OAuth2 client credentials; access tokens last 48 hoursPOST /{projectKey}/products/{id}/images — uploads the actual image file to a product variant, capped at 10 MB, JPEG / PNG / GIF onlyPOST /{projectKey}/products/{id} — attaches an asset to a product by URL reference instead of upload (addAsset / setAssetSources), identified by its Asset.keyPOST /{projectKey}/categories/{id} — attaches category imagery by URL reference (addAsset); CommerceTools has no byte-upload endpoint for categoriesGET /{projectKey}/products?where=…sku… — resolves a SKU to its product id, so each asset can be matched to the right productGET /{projectKey}/products/{id} — reads a product back to check whether an asset is already attached before writing, preventing duplicatesGET /{projectKey} — lightweight health check confirming the credentials and project are reachable |
Not applicable, endpoints exist | Axelerant |
| Big Commerce | PADI Engineering | Endpoints existPOST /v3/catalog/products/{id}/images — uploads a product image as a multipart file up to 8 MB, or points to one by URL; the two are mutually exclusive and each call carries one imagePOST /v3/catalog/categories/{id}/image — uploads a category image as a multipart file, capped at 8 MB, JPEG / GIF / PNG / ICOPOST /v3/catalog/brands/{id}/image — uploads a brand logo; accepts multipart form posts onlyPOST /v3/catalog/products/{pid}/variants/{vid}/image — sets a variant image, 1 MB as a form post or up to 8 MB when passed by URLGET /v3/catalog/products?sku:in=a,b,c — resolves SKUs to product ids in batches, so assets can be matched to the right productsGET /v3/catalog/products/{id}/images — lists a product's images with paging only, no filtering, so duplicate checks mean scanning the full listGET|POST /v3/catalog/products/{id}/metafields — reads and writes product metafields, the only place the integration can store sync state to stay idempotentNot available: two asset types cannot be delivered through the API at all. Product videos can only be linked as a YouTube video id, so the video file itself never passes through Big Commerce. Digital product downloads can only be attached manually through the control panel or over WebDAV, as the API does not support attaching them. |
Not applicable, endpoints exist | Axelerant |
| Django | Axelerant | To be builtPOST /api/dam/assets/ — receives an asset as a multipart upload of the file plus its metadata, stores it in the system, and returns an external id the integration can track it byGET /api/dam/assets/?source_asset_id={id} — looks up whether an asset has already been delivered, by its source id; without this check, every retry or recovery pass creates duplicatesPATCH /api/dam/assets/{id}/ — updates an existing asset in place, either refreshing its metadata or pushing a new version of the fileGET /api/dam/ping/ — lightweight authenticated health check confirming the endpoint and credentials work before a sync runPlus the surrounding contract: token-based auth on every call, rate limits applied per token, and a declared maximum upload size the integration can plan around. |
Axelerant, as the existing owner | Axelerant |
| DomiKnow | PADI Engineering | To be builtMore open questions on what needs to be provided.POST /api/dam/assets/ — receives an asset as a multipart upload of the file plus its metadata, stores it in the system, and returns an external id the integration can track it byGET /api/dam/assets/?source_asset_id={id} — looks up whether an asset has already been delivered, by its source id; without this check, every retry or recovery pass creates duplicatesPATCH /api/dam/assets/{id}/ — updates an existing asset in place, either refreshing its metadata or pushing a new version of the fileGET /api/dam/ping/ — lightweight authenticated health check confirming the endpoint and credentials work before a sync runPlus the surrounding contract: token-based auth on every call, rate limits applied per token, and a declared maximum upload size the integration can plan around. |
TBD | Axelerant |
| SFMC | Fast Slow Motion | To be builtMore open questions on what needs to be provided.POST /api/dam/assets/ — receives an asset as a multipart upload of the file plus its metadata, stores it in the system, and returns an external id the integration can track it byGET /api/dam/assets/?source_asset_id={id} — looks up whether an asset has already been delivered, by its source id; without this check, every retry or recovery pass creates duplicatesPATCH /api/dam/assets/{id}/ — updates an existing asset in place, either refreshing its metadata or pushing a new version of the fileGET /api/dam/ping/ — lightweight authenticated health check confirming the endpoint and credentials work before a sync runPlus the surrounding contract: token-based auth on every call, rate limits applied per token, and a declared maximum upload size the integration can plan around. |
TBD | Axelerant |
Two downstream systems are already served by an existing asset source today, and others may surface during discovery. Any such source is in scope for migration into Acquia DAM, but migrating the assets and cutting over the integration are separate steps, and nothing is switched off between them.
| Existing source | Serves | Downstream consumer | Interim state | Retires when |
|---|---|---|---|---|
| CloudinaryStore assets | Product and category imagery | B2C Store, pro.padi.com | Continues as-isRemains the serving source for Store and pro.padi.com. | B2C Store and pro.padi.com are both integrated with Acquia DAM and consuming from it |
| Other sourcesTo be confirmed | To be surfaced during discovery | Not yet known | Assumed liveTreated as live until assessed. | Same principle. No retirement before the dependent system is cut over |
Assets held in Cloudinary and any comparable source will be migrated into Acquia DAM as part of the wider PADI asset migration, so that Acquia DAM becomes the single governed source of truth.
Migration alone does not change how downstream systems are served. Each integrated system stays connected to its current source until Acquia DAM is integrated for that system, at which point it is cut over to consume assets from Acquia DAM. No existing source is retired ahead of that cutover, so Cloudinary and any comparable source continue to operate as-is in the interim.
Assets held in the existing source move into Acquia DAM as part of the wider PADI asset migration, with its mapping and validation logic, so governance and search live in one place.
Migration alone changes nothing downstream. The existing source stays authoritative for its consumer, and no source is retired at this point.
Build the Acquia DAM integration for the downstream system, connector or API.
A single delta run picks up everything added or updated in the source since the bulk migration, so nothing is left behind when the switch happens.
The system is pointed at Acquia DAM and consumes assets from it. From here, new assets are added to Acquia DAM.
Once nothing depends on the old source, it is stood down and no further syncing is needed.
The initial migration is a point in time. Assets keep being added and updated in Cloudinary and any comparable source while each downstream system waits for its cutover, so Acquia DAM starts drifting from the source the moment migration finishes. Three options for handling that delta, until each system consumes from Acquia DAM and the question falls away.
updated_at later than the bulk migration, once per source as its consumer cuts over.The delta only needs managing in the window between migration and cutover, and during that window the source stays authoritative for its consumer. Staleness in Acquia DAM therefore carries little risk, and a single delta run immediately before each cutover closes the gap.
Option 2 earns its cost only where a source has to stay authoritative well beyond cutover, or where near real-time parity is needed sooner. Option 3 is worth holding as a stop-gap for low-volume sources. This is a proposal for PADI to confirm, not a settled decision.