About & methodology

What the DAM Wiki is

The DAM Wiki is an independent, vendor-neutral reference on Digital Asset Management (DAM) platforms. It has two parts:

• A reference space per solution: overview, features, API, integrations, public resources, a dated changelog and a full list of sources. Each fact is cited.
• Weekly industry news: one digest per ISO week covering product releases, API changes and deprecations, AI features, acquisitions, funding, partnerships, analyst reports and standards (see the news archive).

A comparison table and a glossary sit on top of these.

Publisher: DAM Wiki. The wiki is maintained by people who build DAM integration tooling; no vendor pays for or reviews its content.

Scope

Ten solutions are covered as of 2026-10-01:

How new vendors enter. The weekly news process tracks DAM vendors that appear in the news but are not yet covered. Each one gets a row in the watchlist recording when it was first seen, how often it has come up and why it could be worth covering. The editor decides which vendors to add; the vendor is then registered and researched with the same method as the others. Coverage depends on relevance to DAM practitioners and integrators. Vendors cannot pay to be added.

How pages are built

• Public sources only. Pages are built from documentation anyone can read: API references and specifications, developer portals, help centres, release notes, product pages, press releases, marketplace listings, public code repositories and package registries, analyst press releases and trade press.
• No authenticated calls. Research never logs in to a vendor platform or calls an API with credentials. The only live checks are unauthenticated requests to public endpoints, such as an OpenID discovery document or the error a protected endpoint returns. These are marked .
• No customer data. Pages never name customer tenants or hostnames (URLs use a {tenant} placeholder) and never include data seen on a customer instance, credentials or anyone's internal strategy. Customer names appear only when the vendor has published them.
• Synthesis, not copying. Vendor documentation is paraphrased and organised into tables. Quotes are limited to short phrases.
• Official specs stored verbatim with provenance. When a vendor publishes a machine-readable API specification (OpenAPI, Postman collection), the wiki may keep an unmodified copy in the solution's specs/ folder. A README there records the source URL and the retrieval date. The API pages are partly derived from these files.
• Honest gaps. If something is not published, the page says so with one fixed label: Not public (the vendor does not publish it), Behind login (it exists but needs customer or partner access), Unknown (not found) or N/A. Pages do not guess figures such as rate limits, prices or customer counts.
• Same structure for every solution. All solution pages follow shared templates, so the same question is answered in the same place for each vendor.

Confidence markers and citations

Every non-trivial fact carries a confidence marker and a citation.

Citations. A citation such as [[S12]] points to row S12 on that solution's Sources page (for example Canto — Sources). Each row gives the title, the URL, the source type, the date it was accessed and notes. Source ids are local to each solution, so S12 on one solution's page is a different source from S12 on another's. Glossary entries use their own ids (G1, G2, …), listed at the end of the glossary. News items always link straight to the primary source: the vendor newsroom first, then a press wire, then trade press.

Practitioner confirmations. A few facts are not documented publicly but have been confirmed by the wiki's editor through hands-on use of the product. These are recorded as their own row in the Sources page, labelled as a practitioner confirmation with the marker and no URL, and the row lists exactly what was confirmed. An example is Keepeek source S115, which covers deployment options, an export limit, notification scripts and SSO protocols. They follow the same rules as everything else: vendor-level facts only, nothing about a specific customer instance. Readers should give them the weight of a single expert observation, not of vendor documentation.

Freshness

• Every page carries a last_verified date (YYYY-MM-DD). All dates on the wiki are absolute.
• Refresh thresholds: API and integrations pages are queued for re-verification when last_verified is more than 90 days old; other solution pages after 180 days.
• Event-driven refresh: if a news item about a solution is tagged api-change, deprecation, release or m-and-a, the affected pages are queued at once, regardless of age.
• Weekly cycle: each week the news digest is written, news items are added to the changelogs of the solutions they concern, internal and external links are checked, pages are checked against their templates, and stale pages are added to the refresh queue. Priority order: API changes, then acquisitions, then missing solutions, then stale pages.
• Each solution's changelog keeps a dated history of product and company events, so readers can see what changed since a page was last verified.

Who does the work: AI agents under human editorial control

Most research and maintenance is done by AI agents (large language model agents), each with a narrow role and written instructions:

Each agent may write only to its own part of the wiki. For example, the news agent never edits solution pages. A human editor:

• sets the rules (style guide, templates, the hard rules above) and the scope,
• decides which vendors are added and which research runs are launched,
• decides when changes are published (agents do not publish anything themselves),
• supplies the practitioner confirmations described above, which are always labelled as such.

AI agents can misread or misattribute a source. Three things limit this: each fact links to its source, each page shows its verification date, and unverified items carry a Unverified marker. Readers should check the cited source before relying on a fact for a decision.

Corrections

• How the wiki flags its own doubts: unverified or conflicting facts are marked Unverified with the reason inline (for example, when two official sources disagree, both are cited and the conflict is described). Gaps are labelled Not public, Behind login or Unknown instead of being filled with guesses. Dead links are marked with the date of the check and queued for repair.
• Corrections are welcome from vendors, practitioners and readers, especially when backed by a public source. Contact: contact@damwiki.com.
• Accepted corrections are re-verified against a public source, the page's last_verified date is updated, and notable changes are recorded on the page (old value → new value).

What the wiki does not do

• No rankings, scores, verdicts or "best DAM" recommendations. Comparison pages show sourced facts side by side and link to the cited pages.
• No paid placements. Vendors cannot pay for coverage, position or wording.
• No affiliate links. No link on the wiki earns a commission.
• No vendor sponsorship. No vendor funds, reviews in advance or approves pages.