Which APIs provide brand assets and guidelines?

TL;DR

Choose by whose brand your product works on and what each step needs. Brandfetch and Logo.dev look up any company’s public logos, colours and details from its domain. Platform APIs from Frontify, Bynder and others read the files and pages a customer already keeps there. For agents that make work for the same brands again and again, use Rainbrand: it maintains each brand, returns the guidance and files each task needs and checks finished work against the brand. Many products pair a lookup at signup with a maintained brand for the work that follows.

Start with whose brand it is

Search for a brand API and you’ll mostly find logo lookups compared on coverage, file formats and price per call. That’s a useful comparison if you need logos for companies you don’t control. It doesn’t answer the question AI product teams run into next: when an agent makes work for a customer’s brand, where do its instructions come from, and who keeps them right?

Three questions sort the field: whose brand it is, who keeps it current, and what your code gets back. Their answers separate three kinds of API.

The sections below take each column in turn, then follow one product that uses all three.

Lookup APIs

A lookup API holds records for millions of companies. You send an identifier, usually a domain, and get back what that company presents publicly. Nobody at the company has to sign up for it to work.

Brandfetch covers more than 50 million brands, according to its developer site. Its Brand API returns logos, colours, fonts, images and company details from a domain, website URL, work email, stock ticker, ISIN or crypto symbol, and indexes a brand live if it isn’t in the dataset yet. Fonts come back as a family name with a role (title or body) and an origin (Google Fonts, custom or system), not as font files. The Brand Context API is aimed at grounding models: tagline, mission, value proposition, audience segments, products, a summary of voice and visual style, and up to five competitors, as JSON or as Markdown for a prompt. A free Logo API serves logos from a CDN link. The Brand and Brand Context APIs take an API key as a Bearer token; the Logo API takes a client ID in the URL.

Brandfetch says brands “submit and edit their own profiles directly”, and that the rest is extracted from websites and official channels and reviewed by a person. Since a May 2026 change, brands claimed by their owner or verified by Brandfetch keep their curated logos, colours and company details instead of having them replaced by the next crawl. As of October 28, 2026, its pricing page lists a free plan with 100 one-time brand fetches and a Growth plan from $129 a month (or $1,188 a year) for 2,500 fetches a month, shared across the Brand API, Brand Context API and Transaction API, with overage at $0.10 a fetch. Logo CDN requests have a separate allowance, so don’t count brand fetches and logo requests as the same unit.

Logo.dev starts from the image. Its CDN serves a company’s logo from a URL with a publishable key that’s safe in browser code. Its Brand API, called from your server with a secret key, returns a company’s name, description, colours, social profiles, logo, wide brandmark and social banners, looked up by domain, ticker, ISIN, crypto symbol or name. Logo.dev’s own comparison with Brandfetch notes that its profile has no fonts. Paid plans get webhooks when a brand you follow changes, and anyone can send a correction through its update form. As of October 28, 2026, its pricing page lists a free Community plan with 500,000 CDN requests and API access (commercial projects on it must show an attribution link), Startup at $33 a month and Pro at $150 a month. A brand profile costs 5 API credits; purchased credits cost $10 per 1,000, so that’s $0.05 at the published purchase rate. Included plan credits, and the rule that repeat lookups of one brand within 24 hours are billed once, affect what you actually spend.

Lookups are the right tool when your product needs facts about companies it doesn’t control: logos on CRM records, a signup form prefilled from a work email, a sales deck in a prospect’s colours. They describe a company’s public face, and that’s also where they stop when an agent is doing a brand’s own work:

• Rules aren’t public. “Never recolour the logo” and the claims legal has ruled out live in the brand guide, not on the homepage, so a crawl can’t find them. Brandfetch’s voice and style fields summarise how the brand comes across, which isn’t the same as the team’s rules.
• Sub-brands share a domain. Brandfetch resolves any URL to its registrable domain, so a product with its own colours on the company’s site returns the parent company’s profile.
• Decisions run ahead of the website. A palette approved this month isn’t on the site until the redesign ships.

An owner who claims their Brandfetch profile can keep the public logos and colours right. The rules, unpublished decisions and font files an agent needs come from the brand’s own team. Rainbrand vs Brandfetch goes into that difference in detail.

Brand platform APIs

If a customer already runs its brand in a brand management platform or a digital asset management system (DAM), that platform’s API is the direct route to their approved files and, on some platforms, their guideline pages. These APIs work on the customer’s own account: your product connects with their authorisation and sees what their user can see. The platforms differ most in whether guideline content is readable as data.

A few details matter when you build on them:

• Frontify is direct about how its MCP server reads guidelines. Its prompting guide says the server uses Frontify’s Content API, which “doesn’t yet support semantic search or navigation hierarchy”, so the agent has to be told which brand and page it wants.
• Bynder also has an API for creating AI agents and running them on assets in the DAM. Its Brand Compliance Agent audits assets in the DAM against brand and legal guidelines.
• Canva limits what you can do with a Brand Kit outside Canva. Its MCP usage policy says Brand Kits retrieved through MCP may only be used to generate or modify Canva designs, and its list-brand-kits tool returns each kit’s name, ID and thumbnail. If your customers design in Canva, send the work to Canva.

Pricing is usually tied to the platform plan. Frontify charges by monthly active users through sales. Bynder and Brandfolder build custom packages (Bynder, Brandfolder). Standards puts its API on the Enterprise plan; its Pro plan starts at $40 a month and includes its MCP server and a Markdown guidelines file (pricing, AI integrations). Canva’s Brand Template and autofill endpoints need the connected user to be on a plan that includes them. Ask each provider which API capabilities your contract includes.

These APIs return what’s stored, and most of it was written for people: pages, files and metadata. Your code or your agent still decides which rules apply to the task in hand, and a rule that exists only as a picture on a guideline page reaches the agent only if its model reads images. You also build and maintain one integration per platform, and each one helps only the customers who use that platform. Where your customers keep their approved files in Frontify or Bynder, connect to it for those originals. The comparisons with Frontify, Bynder and Brandfolder go deeper on those platforms.

Maintained brand APIs

The third approach is to call a brand that’s maintained for agents to use, which is what Rainbrand does. You add a brand from its sources: a website, a brand guide PDF, logo and font files, images, documents or written direction. Rainbrand turns those sources into a profile with colours, logos and type, written guidance on applying the brand, and the brand’s files. Your product can add a brand for each customer, in your own account or in a team.

What your code does with it:

Request a Brief

Describe the task and get back the guidance and files it needs, not the whole brand. Each Brief records which version of the brand it used.

Request a Review

Check finished work against the brand and get a verdict and reason for each check, with evidence where available. Your own tools make the revisions.

Prepare an edit

Describe a change. Rainbrand prepares it without touching the active brand; you can inspect or refine it, then apply or discard it.

Export a Brand Skill

Get the complete brand as a versioned snapshot, as data or as a folder, when another system needs all of it.

The API quickstart runs the core loop in a few calls. Adding a brand and asking for a Brief looks like this:

# Add a customer's brand from its website and brand guide
curl -X POST https://www.rainbrand.com/api/v1/brands \
  -H "x-api-key: $RAINBRAND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sources": [
      { "kind": "website", "url": "https://acme.com" },
      { "kind": "file", "url": "https://files.acme.com/temp/brand-guide.pdf" }
    ]
  }'

# Once the brand is ready, request a Brief for one task
curl -X POST https://www.rainbrand.com/api/v1/briefs \
  -H "x-api-key: $RAINBRAND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "brandSessionId": "<brand id>",
    "task": "A 1080 x 1080 Instagram post announcing Atlas Pro to product designers."
  }'

A completed Brief holds Markdown guidance for the task and the files selected for it. Each file is labelled as a logo, an image, a font or a rendered font specimen, with its media type and a stable URL, so the step that renders the output can place the real file. The full Brand Skill goes further on type: each typography role has a name and a weight and, for a custom font, the font files themselves. A role with no usable file says so and gives the reason.

An earlier demonstration shows what that looks like. We added Eager, a juice brand, to Rainbrand from its website, then had Claude invent a flavour and build its launch campaign. These are two of the typography roles in the saved brand profile:

[
  {
    "name": "Primary display and text",
    "weight": 500,
    "font": {
      "source": "custom",
      "family": "P22 Mackinac Pro",
      "fileUrl": "/examples/eager/fonts/p22-mackinac-pro-500.woff2",
      "format": "woff2",
      "fileWeight": 500
    }
  },
  {
    "name": "Secondary heading and buttons",
    "weight": 500,
    "font": {
      "source": "unavailable",
      "family": "Times New Roman",
      "reason": "System font"
    }
  }
]

The first role gives a renderer the actual font file and the weight to set it in. The second tells it there’s no file to fetch. This is the copy saved for the example page, not the current response schema: today’s Brand Skill response gives each font file a signed URL, a checksum and, where available, a rendered specimen, so build against the reference. The excerpt shows the test to apply to any candidate API. Can the step that renders the output use the real file, and does it know what the file is for?

Your own server calls Rainbrand with an API key. When people connect their own Rainbrand accounts to your product, you use OAuth. You can also give your agents MCP access to the brands you add through the API, so a pipeline and an agent work from the same brand. Plans are monthly credits that cover Briefs, Reviews, new brands and edits, with the API and MCP included; current plans are on rainbrand.com/pricing.

Where it stops: Rainbrand doesn’t keep a directory of other companies’ brands. A new brand takes a while to analyse and uses credits, so it suits brands you’ll work on repeatedly, not enriching thousands of CRM rows. It isn’t a DAM, and it doesn’t document webhooks as of October 2026, so check a brand’s active version before you reuse a cached copy.

One product, three APIs

Say you build a tool that makes launch graphics for software companies, and Acme signs up with a work email at acme.com. Each kind of API does a different part of the job:

1. At signup, a lookup. A Brandfetch or Logo.dev call on acme.com returns Acme’s logo and colours, so the first screen already shows Acme’s brand. It costs one lookup, and nobody at Acme has to do anything.
2. When Acme connects its DAM, the platform API. Acme’s design team keeps the approved logo files and Atlas Pro screenshots in Bynder. With Acme’s authorisation, your code reads them from Acme’s portal instead of using whatever the website happens to show.
3. For the work itself, a maintained brand. Your product adds Acme’s brand to Rainbrand from acme.com, the brand guide PDF and download links for the Bynder files. For each graphic it requests a Brief for the task, generates with whatever model you use and requests a Review before showing the result. When Acme gives Atlas Pro its own accent colour, your product prepares a brand edit, checks the proposed change and applies it. Briefs requested after that use the new colour.

Neither Rainbrand nor Bynder documents a connector to the other as of October 2026, so passing the files across in step 3 is your code’s job. For the rest of that design, see how to add brand context to your AI product, how to manage your customers’ brands and how agents retrieve brand context at runtime, which covers caching by brand version.

If your agents connect through MCP

You may not need integration code at all. Most of these providers also run Model Context Protocol (MCP) servers, which assistants such as Claude, ChatGPT and Cursor can connect to and call: Brandfetch, Logo.dev, Frontify, Bynder, Standards, Canva and Rainbrand all document one.

The same split applies. A lookup server answers “get me this company’s logo”. A platform server searches what a team has stored. Rainbrand’s server prepares a Brief for the task and reviews the work against the brand. Which MCP servers provide brand guidelines and assets compares the servers, and MCP or REST API for brand context covers which interface suits which caller.

Check the payload before you choose

Take one task your product runs often and write down what it consumes. For a launch graphic, that’s usually:

• the logo files it places, and which version goes on which background;
• exact colour values, and when each one is allowed;
• the font files and weights for each type role;
• rules the website doesn’t show, such as claims to avoid or how to write a product name;
• reference images of finished work;
• how the finished work gets checked, and how a correction reaches the next task.

Then mark where each item can come from. A lookup can supply what the company already shows the public. A platform API can supply files the customer keeps there. Rules, unpublished decisions and corrections that must carry into future tasks need a maintained brand, and the API quickstart covers that part. Where an API returns a file but leaves open how to use it, your product still has to make that call, so keep the source and brand version with each result.