Good APIs are an essential part of good code. They\u2019re the boundaries that developers draw when we split up projects, create libraries, and share our work. As Robert Frost said long ago, \u201cGood fences make good neighbors.\u201d If he were alive today, he would be writing this poem about APIs.\n\nIncreasingly, good APIs are also the foundation for a good business. They\u2019re not just a gateway to some data and decision-making intelligence, but a product designed to monetize it. APIs track their users and figure out a fair way to bill them.\n\nAlas, creating these APIs is not as simple as opening a TCP\/IP port and waiting for the money to roll it. Unleashed this way, an API will take requests from every device on the internet, and all of the chaos, both malicious and innocent, will start knocking on the enterprise\u2019s door. The challenge is to make an API easy-to-use and welcoming to the right developers while impenetrable to the wrong ones.\n\nHere are 14 common API issues that can trip up your API strategy.\n\nOverlooking the price of exfiltration\n\nMany cloud providers bill for a long list of events and some are easy to forget. The cost of a machine per hour is obvious, but many forget that the bill can include \u201cdata exfiltration.\u201d Alas, the main job of an API is to exfiltrate data to the users. Make sure to take this cost into account when pricing your API \u2014 and also when sketching out the architecture.\n\nIgnoring the \u2018data format tax\u2019\n\nSome data formats such as XML are not as efficient as others, and this can affect the size of the data packets that your API will return. One of my friends still likes to brag about how she cut the data bills for her company by more than 40% just by getting rid of extra tags and cruft in the data format. Keep the data format as lean as possible and keep the data focused on only the necessary bits to keep your bandwidth bills manageable.\n\nFeature bloat\n\nSometimes developers like to be helpful and include extra bells and whistles. Most of the time, these don\u2019t cause any problems, even if they aren\u2019t used. But sometimes they leave security holes that go unnoticed.\n\nThe programmer who added the ability to execute arbitrary code to the Log4J library didn\u2019t plan to create one of the worst security bugs in internet history, but when people forgot about the power of this seldom-used feature it became just that. In cases like this, it helps not to be too creative or clever. Sticking to the bare minimum is not always the best way to build a great product, but it can be a good way to create a secure API.\n\nForgetting to pre-filter\n\nMost APIs don\u2019t do much work themselves. They take the input and pass it along to some other code. One of the best services that an API can offer is pre-filtering to make sure that the inputs conform to expectations. Many of the worst security bugs came from attacks that abuse the naive goodwill of some API to overflow a buffer or generate an SQL injection attack.\n\nSkimping on testing\n\nMany developers have a few basic test URLs. If the right packet comes back from the API, they assume everything is running smoothly. In reality, the test results are often cached and the simple test URLs may only exercise the first layer. A good test suite will make sure to touch every part of an API, especially its connection with the database and any secondary APIs or services.\n\nCORS misconfiguration\n\nCross-Origin Resource Sharing (CORS) issues can appear when an API\u2019s response is mixed in directly with some other content in a browser. This can be a challenge for some API users who rush into using the API. Sometimes the answer is adding the tag Access-Control-Allow-Origin to the headers. Sometimes it\u2019s better to build a full proxy into the stack.\n\nChoosing the wrong authorization\n\nFiguring out the right amount of authorization for your API is a bit of an art. Some data isn\u2019t too sensitive. The API\u2019s only job is to track users to figure out any bills. For these simpler cases, an unchanging random key may suffice. Other APIs, though, protect personal information that may be incredibly sensitive. For these cases, more secure protocols such as OAuth 2.0, OpenID, or JWT are better choices. There are already good libraries for both ends of the protocols so upgrading the security doesn\u2019t require writing much new code.\n\nNot looking for log file anomalies\n\nWhen the software is running and there are no panicked phone calls from customers, programmers tend to take a nap. The log files for APIs, however, can help flag danger before it occurs. Are any particular parameters causing more trouble for the software? Does the load spike on particular days, at particular times, or when one customer shows up? Spending just a few minutes skimming the log files for bad response times can highlight where your hardware is underpowered or your software is glitching. Fixing those issues now will prevent a real meltdown later when some perfect storm delivers several nasty datagrams at once.\n\nCaching incorrectly\n\nAPIs often want to speed up responses and save computation by caching the results for common questions. When caching works well, everyone gets an answer that\u2019s still fresh enough for their purposes. But when caching is overly aggressive, users end up with stale answers and no way to know when they were generated. Using little or no caching will solve this problem, but at the cost of more computation and complexity. Finding the right balance can be a challenge.\n\nRolling your own vs. using a framework\n\nAPIs are now common enough that programmers have built good frameworks such as Swagger, OpenAPI, or any of the commercial versions from the cloud companies. You just write a few lines to specify the parameters and the framework does most of the work. These frameworks have good filters for stopping abuse and offer modern metering to track usage. Creating your own version is increasingly foolish.\n\nIgnoring a free tier\n\nIf your API is meant for a general audience of developers from a wide range of companies, then a free tier can be the simplest way to attract new users. If coders need to ask the boss for a budget line and authorization, it\u2019s harder for them to experiment and show everyone what your API can provide. The danger, though, is that the free tier will be so generous that these developers continue to use the API without becoming paying customers. Finding that right amount is challenging and API-specific. Some APIs are easy to cache because the underlying data doesn\u2019t change and that means free users may be able to stretch access. Be stingy with data that\u2019s easy to cache for long periods of time. But consider being more generous if the main output grows stale quickly or might never be cached.\n\nMispricing an API\n\nThe greatest challenge for an API manager who wants to sell access is finding the right way to price the data. Set the number too low and you miss your revenue targets. Set it too high and people walk away. All standard techniques for marketing and pricing are fair game. Some companies set aside premium tiers to capture revenue from big users. Others set a high public price and then offer generous private deals. There\u2019s no one answer to the problem and people in business school write PhDs on these marketing challenges.\n\nNot taking advantage of serverless\n\nTools such as Cloudflare Workers or AWS\u2019s Lambda aren\u2019t right for every API, but they can be ideal for many. They deliver a simple price point that\u2019s almost directly proportional to usage making it much simpler to design a working business model. If the cloud company charges $X for each function invocation and each API call turns into one function invocation, well, it\u2019s not hard to see that you\u2019ll need to charge at least $X for each API just to break even on the infrastructure. All APIs have other costs and some may be substantial but at the very least, serverless models make it easier for bean counters to price out some of the variable costs for running an API.\n\nNot having fun with error messages\n\nWho first created the custom 404 message? There are several opportunities in each API to inject some humor. Empty or incorrectly formatted requests are obvious, but your particular API might have good places to hide Easter eggs. The engineering teams who design Siri and Alexa needed to have a response to \u201cOpen up the pod bay doors.\u201d What will yours be?