What you let others do with your image is just as important as what you let them do with your API.

Hosting a free-to-consume public API is a powerful tool for expanding your functionality and branding into entirely new networks. But many APIs lack comprehensive and digestible guidelines to protect their brand. Without a developer Branding Guide you leave your company name, product name, logo, style, and message open for reproduction in untasteful or even illegal ways.

For free APIs, data and functionality is given to third party developers to integrate into their apps in exchange for outsourced R&D and spreading brand awareness. Attribution is therefore commonplace, and at times desirable for third party applications as it helps establish their credibility with end users. Therefore, most platforms establish some sort of branding guideline for the API consumer to follow based on their platform policies.

In this walkthrough, we’ll lay out typical brand guidelines that providers offering a public API should use to ensure their company logo, style, and message is reproduced in the best way possible on third party channels. It’s ok to be specific throughout, as specificity will help your developers in the long run. This is unique from a press kit or internal design style guide as it is developer focused — similar to a partner or affiliate marketing guide — making it an important asset to carefully prepare and maintain.

We’ll help decipher a bit of design jargon so that any provider, small or large, can offer a brand guide and asset package that controls how developers implement the API provider’s company image within their apps.

Platform Strategy Dictates Brand Requirements

First, keep in mind that your branding guidelines are part and parcel of your greater platform policy and business model. The monetization strategy you choose will likely impact the level of attribution you require of apps. If the API is free use, high attribution will be necessary so that your marketing return covers the opportunity cost. If the API is pay-to-play, the income generated will hopefully outweigh the need to demand attribution.

Strict brand guidelines may be a huge turn off for some developers looking to leverage your API. Imagine if every programmatically triggered Twilio SMS was accompanied by “Sent by the Twilio API.” That would be annoying, and would de-legitimize the developer’s app, and confuse the end user.

Likewise, if your SDK forces an in-app user to leave the original app to a different channel dominated by the API provider’s branding, again, you’re doing things wrong. Especially if developer consumers are intending on monetizing their app, they will not likely sacrifice their image for your functionality. Thus, a happy medium needs to be forged.

Brand Guide Components

Now we’ll overview the main steps to create a brand guide that helps APIs control how their branding — message, name, logo, color palette, placement, attribution, and more — appears on third party apps.

Message

Branding first starts with creating a story. The tone, perspective, and voicing that make up your company’s copywriting should also resonate throughout your API’s home page, developer center, and descriptions of example API use cases.

An API brand guide should therefore define the platform functionality so that if developers describe the integration on their own channels, they explain it correctly. It doesn’t hurt to also explain the voicing or tone the provider company adopts to communicate with its userbase.

Naming

Most closely guarded is a company’s registered name or trademark. Third party apps shouldn’t reproduce the provider’s name or resemble it too closely, therefore API Terms of Use typically protect brand identity by listing example names or phrases that are not allowed. Thus, your guide should:

• State your company name and proper capitalization — Example API,
• Not allow portmanteaus that include some portion of the provider’s name,
• List other acceptable/unacceptable naming conventions for services your consumers may also reference.

In general, it’s a good idea for developer consumers to give their service a unique name that is distanced from the provider’s. Above all, third party apps shouldn’t confuse or mislead users regarding your affiliation — the brands must stand alone.

Attribution

If the API provider’s brand must consistently accompany third party app behaviors, be explicit in its implementation. Should branding link to the API provider’s home page at all times? Remember when, where and what:

• Communicate when your brand should appear: Many APIs require branding at all times the API is used to access the provider’s data. A more relaxed method is to require your logo at initial sign-in, and/or in the app’s About page.
• Communicate where your brand should appear: Perhaps the API is called to query a database, populating a search field. In that case your company logo should be located near the search field. For other situations, delineate where on the user interface your branding should appear — Top Left, Top Right, Center, Bottom Left, Bottom Right, etc.
• Communicate what exactly should appear: Clearly specify what assets and attribution copy needs to be used and under what circumstances — “Powered by Example API” badge, “works with Example API”, etc.

Giving credit is different than implying an endorsement, so the attribution shouldn’t suggest there is a partnership between the third party developer and the API provider. So this is clear, the provider shouldn’t be the most prominent element or logo on the web page, nor the only branding on the page. The best guides lucidly communicate what level of attribution is required, and use graphical aids whenever possible to help illustrate the point.

The Logo

A tech company’s logo will often come in varying iterations. Many logos include an icon as well as a wordmark, and app icons are often represented in isolation. Explain all components of your logo — the icon, wordmark, the typography used, the relative measurements, and color palette.

For your logo, consider adding stipulations to your branding guide like:

• Describe relative spacing between icon and wordmark
• Establish a minimum acceptable size — i.e. 80px or 25mm for print.
• The third party logo should not resemble the provider’s style in a similar way
• Ensure your logo always links to a specified provider page
• Icon can exist without wordmark, but the wordmark shouldn’t exist without icon
• Don’t add a tagline or motto to the existing logo

If you have logo variations, note which is the best possible brand representation. Logotypes are most accurate and should be used whenever possible, but icons/glyphs are acceptable after brand has been established or if there is limited horizontal space in the UI.

Make sure to note that it’s not acceptable to alter the logo in any way. Embellishments like drop shadow, distortion, or clip masking, as well as inserting the logo in front of busy backgrounds or complex patterns should all be discouraged. So that the logo still remains visible with bright and dark backgrounds, have both a colored, white, and grey/monochrome logo matching your platform’s color scheme. It’s pretty easy to dream up of some hideous logo misuses:

Exclusion Zone

The exclusion zone is the minimum padding, or white space around the logo that ensures the logo is prominently displayed. As pixel distances can be misleading, communicate this minimum safe distance in relative terms — for example, make the exclusion zone half the size of the icon diameter.

This clear space is important to protecting the brand, as it makes sure that third party company logos, phrases, or other graphical elements aren’t displayed too close to your assets.

Color Palette & Typography

What are the colors used within your logo and throughout your branding? Represent your default logo color for a light background, and preferred color for a dark background, and list the specific color hexadecimal as well as RGB, CMYK, and Pantone indicator for each. Our hypothetical API, for example, has a nice evergreen color. Similarly, note the font used on your logotype, headings, and in body text for your general communications.

Brands take time to choose the right colors that match their service image. Unfortunately though, considering the varying browser color settings and screen calibrations across thousands of different devices, it’s hard to match colors exactly. Therefore, have fall back color options for devices or screens with less optimized color grading. As long as your identity is obvious and color not significantly distorted, you should be fine.

Formatting Your Design Guide

The presentation for the guidelines is JUST as important as their meaning. Organize a brand guideline PDF, and have easily accessible digital logo assets.

The Effect of Zero or Poor Branding Guidelines

Image is nearly everything in our web-infused age, as sleek professional design attracts the bulk of screen-watchers. Your program should thus not only seek to incorporate healthy design practice, but associate itself with apps that also embrace quality design.

If you are too lax in protecting your brand you face the prospect of a fragmented and inconsistent development ecosystem. Integrations appear murky, and user data and privacy will come into question. API Evangelist adds that the lack of a branding guide equates to missed value for API programs:

“Even with this being a major concern, I see many APIs implement very poor branding guidelines, giving developers zero direction regarding how to properly provide attribution. This is a missed opportunity to not just protect the API providers brand, but actually extend it and increase its value.”
_{– Taken from Protecting your brand with API branding guidelines}

So, help nourish your developer ecosystem by supplying in-depth guidelines so that developers share your mission.

Final Thoughts

Maintaining consistent platform-wide branding for a company is hard enough as is. Extending that image to social channels can be tricky, and retaining identity within a third party developer’s application is even more difficult.

In this article, we’ve outlined a step-by-step process to create your own API branding guide, modeled after some of the best programs in existence. As spreading platform brand awareness to as many eyes as possible may be a primary objective for a public API, the importance of defining these guidelines cannot be overestimated.

Use this cheat sheet as inspiration for your own program, but at the end of the day, you control your branding, how it is represented and where it is present in the developer’s app. Learn from the developer relations missteps of Instagram and Twitter; if you plan on releasing an API with branding restrictions, do so carefully and in a really transparent way.

Examples of API Branding Guides in the Wild:

Most companies with developer programs have unique brand guidelines as part of their API terms of service. Not everyone is doing it right, but here are some to model:

• Spotify
• Zillow
• Dropbox
• Orange
• Slack
• TokBox
• Walkscore
• NYTimes