Branding plays a crucial role in enabling your customers to distinguish your product as the preferred solution over those offered by your competitors.
Whilst you may think branding sits in the marketing department, in many cases, your branding and proprietary system names are often integrated into your API constructs, for example:
enumerations
request headers
environment variables
code comments
sample data
functions/endpoints
For the most part, this is a non-issue – that is, until your organization undergoes a merger, acquisition, or even a corporate or product name change. Now, suddenly, your API may no longer match the new branding. Since your API is your developers' key interface to your products, your API constructs will also need a rebranding.
Chances are, no one in your organization has considered these issues or the amount of work required to rebrand them.
What do you do if you discover that a rebrand of your API constructs is needed?
The first step in rebranding your API is to build an inventory of everything that needs to be changed and identify the key stakeholders who will be involved.
And don’t forget, branding can exist in your developer learning resources too. Filenames, documentation, portal URLs, technical diagrams, illustrations, and tutorial videos are just a few examples of assets that can contain company names and logos. As with your APIs, all of your learning resources will need a thorough scrub as well.
Armed with your inventory assessment, the next step is devising your strategy. To help you with this, here are three approaches we’ve used for different clients:
Leave your API as is and communicate why the old branding remains. Good communication with your developers is always important, especially for new customers who join post-change and may question any legacy naming. This approach is the simplest, at least, until you have the time to implement scenarios 2 or 3 below. Keep in mind, however, that leaving your old branding in place for too long can make your API feel like legacy code, that you are not investing in maintaining your resources, and create a concern that other inconsistencies may be hidden in your resources. You want to avoid any scenario that could create a negative perception.
Update your API – this is the most invasive approach because it means breaking the contract of your interface. Be sure to set expectations early, document what changes will occur, and help customers along the way to ease their transition. In some cases, your customers' upgrade path could be as simple as copying and replacing all branding instances; in other cases, it may be more complicated. Trial this in a sandbox, just as your customers would, to identify issues before putting them through a breaking update.
Create a whole new version of your API, document the changes, and help customers transition to this new version at their own pace. This is probably your best bet. Hopefully, from an implementation standpoint, this can be a copy-and-replace operation of branding changes and perhaps some URL updates that can be done within certain subsystems at the customer’s leisure.
If your name change resulted from a merger or acquisition, it may involve broader technology changes. This is a good time to reevaluate the design of your API and include any branding changes or removal as part of that process.
If you need a hand, why not give AI a try? We’ve successfully used tools based on Llama 3 to help identify API issues during OpenAPI linting.
Overwhelmed, or need help?
Let us help you rebrand your API and Learning Resources.
With years of technical writing experience, we are adept at all aspects of the developer journey and creating/migrating learning resources. Book a meeting with us today, to find out how we can help you rebrand your API and associated learning resources.