What Is an API Key?
An API key is a secret string of characters that identifies and authorizes an application when it calls an API. It works like a password for software: the calling program includes the key with each request, and the server checks it before returning data or performing an action. Keys let a provider know who is calling, apply the right permissions, enforce rate limits, and cut off abuse. Because anyone holding the key can use it, keeping it secret is essential — a leaked key is a leaked account.
- What it is
- A unique secret token that identifies and authenticates an app to an API
- Format
- Often a long random string, sometimes prefixed like sk_live_ or AIza
- Sent via
- Usually passed in an HTTP header, e.g. Authorization or x-api-key (MDN Web Docs)
- Purpose
- Identifies the caller, sets permissions, and enforces rate limits
- Risk
- A leaked key can be used by anyone; treat it like a password (OWASP)
What an API key really is #
An API key is a long, unique string of letters and numbers that a service issues to identify the application calling it. When your website or app makes a request to an API, it attaches this key so the provider knows exactly which account is asking. In practice a key looks like sk_live_9f2c8b or AIzaSyD-xxxx — deliberately random so it cannot be guessed. The key answers a single question for the server: who is this? Based on the answer, the provider grants the right level of access, counts the request against your quota, and can shut off a key that is being misused. Unlike a username and password that a person types, an API key is used by software, silently, on every call. That convenience is also its risk: whoever holds the key can act as you. Because API connections increasingly power everyday business tools, understanding keys helps you protect them. Our /services/api-crm-integrations page covers how we wire these connections up securely from the start.
What an API key is used for #
An API key does more than open a door — it lets the provider manage how you use their service. First, it identifies you, so the provider can attribute every request to your account. Second, it authorizes access, granting the specific permissions tied to your plan; a read-only key cannot change data, while a full-access key can. Third, it enables metering: the provider counts your calls to enforce rate limits and, on paid services, to bill you accurately. Fourth, it supports abuse control — if a key starts making suspicious requests, the provider can revoke just that key without affecting anyone else. Payment processors, mapping services, email-sending tools, and AI models all rely on keys for exactly these reasons. This is why a single business might hold a dozen keys across different services, each scoped to one job. Managing them carefully keeps your automations running and your bills predictable. Our /services/web-app-development team keeps track of which key powers which feature so nothing breaks unexpectedly.
How to send an API key #
Most APIs expect the key in an HTTP request header rather than the URL, which keeps it out of server logs and browser history. Here is a typical authenticated request.
curl https://api.example.com/v1/customers \
-H "Authorization: Bearer sk_live_9f2c8b1a..." \
-H "Content-Type: application/json"
# Some APIs use a custom header instead:
curl https://api.example.com/v1/customers \
-H "x-api-key: 9f2c8b1a..."API keys vs other credentials #
An API key is the simplest way to authenticate software, but it is not the only one, and the differences matter for security. A plain API key is a single static secret: convenient, but if it leaks, it works until someone notices and revokes it. OAuth access tokens are more sophisticated — they are issued after a user grants permission, they carry limited scopes, and they expire, so a stolen token is useful for a much shorter window. JWTs are a token format often used to carry identity and permissions in a verifiable way. For sensitive systems, providers increasingly prefer short-lived tokens over long-lived keys precisely because expiry limits the damage of a leak. As a rule, use API keys for straightforward server-to-server calls and reach for OAuth when acting on behalf of a specific user. Choosing the right mechanism is part of designing a safe integration. Our /services/website-security team weighs these tradeoffs so each connection uses the least-risky credential that still gets the job done.
How keys get leaked #
API keys leak in surprisingly ordinary ways, and each leak is a potential account takeover. The most common mistake is embedding a key in front-end code — JavaScript that runs in the visitor's browser is fully visible to anyone who opens developer tools, so any key there is effectively public. Another frequent slip is committing a key to a public code repository like GitHub, where automated bots scan for exposed secrets within minutes. Keys also leak through screenshots shared in support tickets, logs that record full request headers, and configuration files accidentally left in a public folder. Once a key is exposed, attackers can rack up charges, exfiltrate data, or exhaust your rate limit, sometimes before you notice. The fix is prevention: keep keys on the server, out of version control, and out of anything a visitor can see. Our /services/website-security page explains how we audit sites for exposed secrets and set up safe storage, since this single category of mistake causes a large share of small-business breaches.
Storing and rotating keys safely #
The safe home for an API key is a server-side environment variable or a dedicated secrets manager, never hard-coded into files that ship to the browser or get committed to a repository. Environment variables keep the key out of your codebase, so the same code can run in testing and production with different keys and no secret ever lands in version control. Beyond storage, rotation matters: periodically generating a new key and retiring the old one limits the damage if a key was quietly exposed months ago. When someone with access leaves your business, rotating affected keys is basic hygiene, much like changing locks. Good providers make rotation painless by letting multiple keys work at once during a changeover. Automating this is part of running connected systems responsibly rather than setting them and forgetting them. Our /services/managed-hosting and /services/care-plans services include keeping credentials stored correctly and rotated on a sensible schedule, so a forgotten key from years ago does not become tomorrow's incident.
Rate limits, quotas and billing #
Because an API key identifies your account, providers use it to control and charge for usage. A rate limit caps how many requests your key can make in a window — say 100 per minute — to protect the service from overload; exceed it and calls return a 429 error until the window resets. A quota is a longer-term ceiling, such as 10,000 requests per month on a given plan. On paid APIs, the key is also how the provider meters billing, so every call your software makes is counted against your account and your card. This has a practical consequence: a leaked key does not just risk your data, it risks your bill, because an attacker's requests are charged to you. Watching your usage dashboard helps you catch runaway costs early and right-size your plan. Understanding these mechanics prevents nasty surprises when a feature suddenly gets popular. If your integrations are hitting limits or costs, our /services/api-crm-integrations team can tune how often your site calls each service.
What small businesses should know #
You do not need to be a developer to make good decisions about API keys, and a few habits prevent most problems. First, know which services your website holds keys for — payment processors, email tools, maps, AI features — because each is a credential worth protecting. Second, make sure whoever built your site kept those keys on the server, not in front-end code a visitor could copy. Third, revoke keys promptly when a vendor relationship or staff member ends. Fourth, keep an eye on usage and billing dashboards for the paid services, since unexpected spikes can signal a leak. These are the same instincts you already apply to passwords and bank cards, transferred to the software that runs quietly in the background. A trustworthy web partner will handle the technical side and explain it in plain terms. Our /services/website-security page and a periodic /free-website-audit are practical ways to confirm your keys are stored safely rather than assuming they are.
Restricting and monitoring keys #
The strongest protection for an API key is to limit what it can do before anything ever goes wrong. Many providers let you scope a key to specific permissions — read-only versus read-write — so a key that only needs to display data cannot be used to delete it. Some also let you restrict a key by referring website, IP address, or the specific API products it may call, so even a stolen key is useless from an attacker's server. On top of restrictions, monitoring closes the loop: usage dashboards and alerts flag unusual spikes or calls from unexpected places, giving you a chance to revoke a key before real damage is done. The principle behind all of this is least privilege — grant each key the minimum access it needs and nothing more. Applied consistently, it turns a leaked key from a disaster into a minor inconvenience. Our /services/web-app-development team configures scoped, restricted keys and monitoring as standard practice, so your integrations follow this principle from day one rather than after an incident.
FAQ
What does an API key look like?
Usually a long, random string of letters and numbers, often with a recognizable prefix. Stripe keys start with sk_live_ or pk_test_, Google keys often begin with AIza, and many others are simply a 32- or 64-character hash. The randomness is deliberate, making the key practically impossible to guess by trial and error.
Is an API key the same as a password?
It plays a similar role but for software instead of a person. Both are secrets that prove who is making a request, and both must be kept private. The key difference is that an API key is used automatically by an application on every call, rather than typed by a human at login, which changes how you store it.
What happens if my API key is stolen?
Whoever holds it can make requests as you — reading data, changing records, or running up charges on paid services until you revoke the key. That is why keys must stay off public code and repositories. If you suspect a leak, immediately generate a new key, retire the old one, and check your usage logs for unauthorized activity.
Where should I store my API keys?
On the server, in environment variables or a dedicated secrets manager — never in front-end JavaScript, a public code repository, or a configuration file that visitors could reach. Keeping keys server-side means they are never sent to the browser, so customers and attackers alike cannot see or copy them from your website.
Can I use one API key for everything?
You can, but you should not. Using separate, narrowly scoped keys for each service and purpose limits the damage if one leaks and makes it easy to revoke a single key without breaking every integration. Many providers also let you restrict each key's permissions, which is safer than one all-powerful credential.
Do free APIs need keys?
Often yes. Even free tiers usually issue a key so the provider can identify you, apply the free plan's rate limits, and prevent abuse. Some public, read-only data feeds allow anonymous access, but most services — free or paid — require a key to track and control how their API is used.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?