The Dark Reality of APIs: What You Discover After You Build

The hidden costs of APIs include bills, limits, outages and upgrade work your business inherits once customers start depending on the service you have connected.

The demo works beautifully. A customer enters an address, the map appears, a payment goes through, and a confirmation arrives. Building the underlying services would have taken far longer.

Then the product goes live.

Traffic arrives in bursts. A background job repeats requests. A provider changes an API version. The founder discovers that the launch budget covered API integration costs, while the operating budget barely considered what would happen afterward.

That opening is an illustrative scenario, not a reported incident. It captures the question worth asking before building a business around external services: what has been saved today, and what must be managed tomorrow?

What an API Actually Gives You

API stands for application programming interface. It defines how software components communicate, allowing an application to request data or actions from another system. AWS uses a weather application requesting information from a weather service as an example.

This article focuses on third-party API risks when using web APIs: services supplied by another organisation and accessed over a network. Internal APIs and operating-system interfaces raise different questions.

An external API can give a small team access to capabilities it could never economically build itself. Payment processing is an obvious example. The trade becomes harder to judge when access is mistaken for control.

Your product may own the customer relationship, while the provider controls an essential operation. That arrangement can work well. It still needs a price, a failure plan, and someone responsible for keeping the connection working.

Hidden Costs of APIs: The Unit Price is Only the Beginning

API pricing per request looks easy to budget. The missing detail is how many billable events a customer’s activity generates.

Depending on the service, a workflow may involve repeated searches, follow-up lookups, background updates, or additional processing. Billing rules differ, so counting visible clicks is a poor substitute for measuring actual usage.

Consider a location-based application. A user searches, changes the search area, and opens several results. Those interactions may invoke different services with different billing rules. A forecast based only on the number of registered users tells you little about the cost of that behaviour.

Google Maps Platform’s cost guidance makes another distinction explicit: setting a budget does not automatically cap usage or spending. Budget alerts notify you; they do not themselves stop further billing.

That is an expensive assumption to get wrong.

Quotas can help control usage, but they also affect whether customers can use the product. Google notes that quota and billing systems are technically separate, so a quota should not be treated as a perfectly precise monetary ceiling.

Before promising unlimited usage, measure the cost of completing a customer task under the provider’s actual charging rules as part of API cost management.

AI API Providers: OpenAI, Gemini, DeepSeek and Qwen

A chatbot subscription can make AI access feel like a fixed monthly expense. Connecting that provider to your own product introduces a different calculation.

For an application built around OpenAI, use the term OpenAI API. ChatGPT is the user-facing product, and OpenAI documents separate billing systems for ChatGPT and its API platform. Chinese-provider examples include DeepSeek and Alibaba Cloud, which offers hosted Qwen models through Model Studio.

Tokens are the units a model processes and generates. The text sent to the model and the text it returns can therefore contribute separately to the bill.

For a hypothetical content-writing tool, compare the cost of an accepted article after revisions. If the application sends earlier conversation text with each new request, that text becomes input again. Caching may reduce eligible charges, but the discount depends on the provider’s rules and the actual request.

This is a planning example, not a ranking of providers. Test the same customer task across the services under consideration, checking the completed result, billable usage and behaviour when limits are reached.

API Rate Limits can Interrupt Growth

A product may have money available and still be unable to make the next request. GitHub’s REST API documentation distinguishes primary quotas from secondary rate limits, which address behaviour such as excessive concurrency or concentrated request activity. It also states that secondary limits can change without notice.

The practical consequence is that a generous headline quota does not guarantee permission to send requests in any pattern you choose.

A scheduled synchronisation job might run comfortably during testing, then encounter limits when customer accounts grow or jobs start together. Adding more workers can increase the pressure if the shared limit remains unchanged.

GitHub instructs clients to respect its rate-limit response headers and wait when directed, including following a Retry-After header where present. A retry loop that keeps asking faster is therefore capable of making the problem worse.

Assess API usage limits using peak behaviour as well as monthly totals. Ask what happens when customers arrive together, background tasks overlap or delayed work resumes after an interruption.

Your Application can Inherit Someone Else’s Outage

The checkout page belongs to your business. A dependency failure can still leave the customer unable to complete the purchase. During API outages, you may have no control over repairing the provider’s service. You do control how long your application waits, whether unrelated features remain available, and what the customer sees.

Microsoft’s Azure Architecture Center describes the circuit breaker pattern as a way to stop repeatedly calling an operation that is likely to fail. Applications can then handle the interruption through reduced functionality, an alternative operation or a clear error message.

The pattern does not restore the provider. It can help contain the damage while recovery happens. The appropriate response depends on the activity. An optional recommendation panel might disappear temporarily. A background task might be queued. A payment operation needs a carefully defined recovery process.

“Try again later” is sometimes the correct response. The problem is discovering that response during an outage, after customers have already been left waiting.

A Timeout Does Not Tell the Whole Story

Suppose an application sends a request to create an order. The connection breaks before a response arrives.

Did the provider create it?

A timeout alone cannot answer that question. The Amazon Builders’ Library warns that a failed or timed-out call does not necessarily mean its side effects never occurred. Repeating an operation can therefore produce an unwanted duplicate.

Stripe documents idempotency keys for safely repeating the same request without accidentally creating another object or performing the operation again. The key lets the service recognise a retry as belonging to the original operation, subject to its documented behaviour and retention rules.

That is different from generating a fresh request each time the application becomes impatient.

Retries also consume capacity. Amazon’s guidance explains how retries can increase load on an already struggling system, and why increasing delays and introducing jitter can help avoid simultaneous bursts.

Every important integration needs answers about idempotency and safe retries: when is another attempt useful, and when is another attempt safe?

“Finished” Integrations Still Need Maintenance

A working connection can have an expiry problem long before it has a code problem.

Shopify’s documentation on API versioning and deprecation says it releases new API versions every three months and supports each stable version for at least 12 months. It also describes how requests targeting an inaccessible version are served using the oldest accessible stable version instead.

That policy offers a migration window. It does not remove the need to migrate.

A response may still arrive while the application is relying on behaviour it has never tested. Teams need to know which API version is actually serving their requests and whether deprecated features remain in use.

Shopify also identifies unversioned interfaces that may change at any time. The protection offered by a stable, versioned API should therefore not be assumed to cover every interface from the same provider.

When budgeting a product, include API maintenance costs and assign ownership for changelog monitoring, compatibility checks and migration work. Otherwise, maintenance becomes an emergency task competing with customer support and new features.

Security Includes the Services You Trust

Keeping a credential out of public code is a useful starting point for managing API security risks. It does not settle every security question.

OWASP’s API Security Top 10 identifies unsafe consumption of APIs as a risk: applications may place too much trust in data received from third-party services. OWASP recommends validating incoming data and avoiding blindly following redirects, among other safeguards.

A recognised provider name does not make every response suitable for direct use in a database, webpage or downstream operation.

There is also an important correction to common API-key advice. Some client-side integrations are designed to use keys visible to the user’s device. Google Maps distinguishes those uses from server-side web-service credentials that should remain secret, and recommends appropriate application and API restrictions.

Treat credentials according to their intended use. A restricted browser key and a powerful server-side secret require different handling.

The business question is wider than where the key sits: what can the credential access, who can invoke the integration, and what limits apply if usage becomes abusive?

Abuse Can Turn Access Into a Bill

A legitimate request can consume an expensive resource.

OWASP’s unrestricted resource consumption category covers risks involving computing resources and paid integrations, including services such as messaging. It describes both service disruption and increased operating costs as possible consequences.

For a hypothetical verification workflow, repeated requests could trigger paid messages without producing a new paying customer. Similar reasoning applies to any feature where the business pays for work that users can repeatedly request.

The existence of a valid API credential does not establish that the activity is economically acceptable.

Consider limits on user activity, request size and costly operations, with monitoring for unusual patterns. The exact controls depend on the service and product. A provider’s overall quota may protect its infrastructure while still permitting more expenditure than your business can tolerate.

Receiving Data Does Not Settle the Right to Reuse It

Caching is often suggested as a way to reduce calls and improve response times. The provider’s terms may limit that option.

Google’s Places API policies restrict prefetching, caching, and storing content beyond permitted exceptions. Place IDs are specifically exempt from the caching restrictions.

The lesson is service-specific: check the applicable terms before designing a permanent database around API responses.

The same care belongs in decisions about sending customer information outward. Identify what leaves the application, why it is needed and which provider commitments apply to retention, deletion and processing. Those answers depend on the service and agreement; the word “API” supplies none of them.

A successful response confirms that a request was processed. It does not, by itself, resolve data rights or privacy obligations.

Switching Providers May Require More than a New URL

Different providers can represent similar information differently. A replacement may use another identifier system, return different fields, handle errors differently or produce results that customers notice.

The earlier Shopify versioning and Google Places examples illustrate how behaviour and data use can be tied to a particular provider. The broader migration cost is a business inference: the more product logic depends on those choices, the more work a replacement can require.

Keeping provider-specific code in a defined part of the application can reduce vendor lock-in and migration work. It cannot make unlike services identical.

A backup provider also adds cost and complexity. It may be justified for an essential operation and excessive for an optional feature. Choose based on the consequence of losing access, then test the replacement rather than assuming it will work.

Before approving an integration, record the following decisions:

This is an editorial planning checklist, not a guarantee against failure. Its purpose is to turn assumptions into decisions before customers depend on them.

What the Demo Leaves Unfinished

APIs can make a useful product possible. Building every capability internally would often cost more and deliver less.

The risk appears when the working demo becomes the entire business case. A connection has succeeded; billing control, failure handling, maintenance and replacement may still be unresolved.

Before launch, choose a customer task and trace it through the external services it uses. Check the charges it creates, the information it sends and the behaviour when a response arrives late or never arrives.

That exercise reveals what the attractive demo cannot: whether the product remains usable, supportable and economically sensible after the connection stops behaving perfectly.