DDM HelpMoving from CMWS
/api/ext/v1): keys in a header instead of the address, ids that never change, a change feed, groups, markets and access — and every new feature. CMWS gets none.Integrations built against the CMWS interface of the old Document Distribution Manager (<old instance>/cmws/v1/) keep working in DDM. When your organisation is moved over, so are your CMWS keys, the ids of your records and the origin_ids your systems gave them. Change the address and nothing else:
before https://ddm.customer.de/cmws/v1/file?apikey=546b9be5a616b5c629be546173&origin_id=PIM-4711
after https://<your DDM>/api/cmws/v1/file?apikey=546b9be5a616b5c629be546173&origin_id=PIM-4711
If your old host name is pointed at the new DDM, the old path /cmws/v1/ answers too, and not even that changes.
The calls, fields, error codes (-1001, -1002, -1003) and the list format (items, current, item_count, prev, next) are those of the CMWS documentation. Ids and flags come as strings, times as ISO 8601 (2026-10-29T08:00:00.000Z); Y-m-d H:i:s is still accepted, as UTC.
How CMWS maps onto DDM
| CMWS | DDM |
|---|---|
| File | A document, pushed through the key's push source — origin_id is its reference there. |
| Category | A category. One under several parents is one category per parent, sharing its id. |
| Territory | A group, named <type>: <title>. |
| TerritoryType | A name: renaming it renames its territories' groups. |
| Locale | The market of its country. Several locales of one country share it. |
territory_ids on a category | read for the territories' groups — and none for a territory that is not listed but would inherit access from above. |
users on a file (user_only) | read for each person, and none for every group the file's categories would let in. |
published_status, publish_for_period | Archived or not; the document's availability window. |
is_highlight, is_highlight_for_period | The highlight; the highlight window. |
generate_watermark | The watermark: each reader's e-mail address on every page they get. PDFs and Office files only. |
Every call acts as the key's person in DDM, with their rights, and is recorded in the audit trail under the key's name.
What behaves differently
- Accepted and sent back, without effect:
published_for_form_factor,orientation,generate_thumbnailand athumbnailpart — the preview is made from the file — and a category'spublished: DDM has no unpublished categories. - A file restricted to users stays restricted for the groups that reach it when you send it. A group given access to its category later sees it too.
- Deleting a category moves the categories below it up and files documents that were only there into CMWS: without category; DDM keeps every document in a category.
- Deleting a territory deletes its group, with its members and every category it opened.
- Deleting a locale removes its market only when no other locale shares it and it is not the default — with every title in it.
- Unpublished files (
published_status0) are archived, and the organisation's retention rules apply to them. - With Distribute only after approval switched on, a pushed file reads
published_status"0"until it is approved. origin_descriptornames your key for your own records only; for another key's it isnull./idsand/originidslist the whole organisation, as before; the numbering of records that never had a CMWS id starts after the highest old one.- CMWS needs the plan's integration API, as API keys do.
Moving on
Your old keys appear under Settings › API access as Old CMWS key. They travel in the address, where many logs keep them; replace one with a new key there — its push source and acting person stay — and send the new key in ?apikey= instead. The integration API does all CMWS does and more, with the key in a header, ids that never change and a change feed.