Who keeps brand data current?
Lookups re-read a company's website every few months, DAMs are kept current by its team, and Rainbrand applies edits you approve. How each reports changes.
Last updated 2026-11-10
Brands change: a new logo, a new colour, a product renamed. Who notices depends on the kind of API.
| Kind | Who keeps it current | How your code hears about a change |
|---|---|---|
| One-off lookups | The provider, by re-reading the company's website, and anyone who sends a correction | Webhooks on Brandfetch's and Logo.dev's paid plans |
| DAMs | The company's own team | Webhooks on Brandfolder, Canto and Cloudinary |
| Agentic brand work | You or your customer, through edits you apply | Rainbrand documents no webhooks; store the version you used |
Lookups
- Brandfetch re-crawls a brand in the background when a request finds it more than three months old. Owners can claim their profile, and since May 2026 claimed or verified brands aren't overwritten by re-crawls.
- Context.dev reuses data for up to three months by default; you can ask for a fresh read.
- Logo.dev updates the image behind the same URL when a company changes its logo.
- Hunter reads the logo a company declares on its homepage.
- Brandfetch, Logo.dev and Context.dev take corrections at an
/updatepage on their sites; LogoKit through a form.
A lookup only sees what is published. A colour approved this month isn't there until the company's website shows it.
DAMs
The company's own team edits assets and guidelines in Frontify, Bynder, Brandfolder, Canto or Cloudinary. Frontify's guideline pages report when they were last changed. Bynder MCP answers from the current published version of each guide. Brandfolder's Smart CDN links and Canto's Direct URLs always point to the current file.
Agentic brand work
In Rainbrand, a change is prepared as an edit, which you review and then apply or discard. Briefs requested after that use the new version. Each Brand Skill is a versioned snapshot, so store the version you used with each result.