An API key is a long random string that identifies your app, not a person, to another company’s service, and the service bills and limits whatever arrives with it. That is the short answer to what is API key: whoever holds the string is treated as you. 6 of the 21 third-party apps I audited shipped a real secret, in a selected set from my June and July 2026 audits.
What is API key: what an API key is, and how an API key works
An API key is a long random string a provider issues to your project and your server sends with each request. The provider checks it and counts the call against your quota and bill. The key identifies the calling app, not a person, so anyone who copies it can call the service as you.
A key is one kind of secret among several that an app holds, and the wider picture, from database passwords to webhook signing secrets, is in secrets management for an AI-built app. The 6 of 21 above counts a set of apps I selected, not a random sample, so it is not a rate for AI-built apps in general.
API stands for application programming interface, so the full form of API key is application programming interface key. An API and an API key are two different things: the API is the set of addresses where a service accepts requests from other programs, and the key is the string your app attaches to those requests.
Web API keys follow the same four steps at every provider on this page, in my reading of their docs:
- The provider generates the string for your account or project, in its own dashboard.
- Your server sends it with each request, in a header the docs name:
Authorization: Bearerat OpenAI, HTTP Basic Auth or a bearer header at Stripe,x-goog-api-keyat Google. - The provider looks the string up and checks that the key is active and allowed to make this call.
- The provider counts the request against your quota and your bill.
That, as I read the providers’ docs, is how API key authentication works on the provider’s side: a lookup and a permission check on every call, with no login step before it. Google draws the line in its docs: API keys identify the calling project, and authentication tokens identify a user. A stolen Google key does not run out either: once a key is stolen, Google says, “it has no expiration, so it may be used indefinitely, unless the project owner revokes or regenerates the key.” The missing login and the missing expiry are what make a key convenient, and they are what make a copied key dangerous.
OWASP’s REST Security Cheat Sheet treats keys as one way to reduce the risk of a public service being farmed into excessive bills, and it adds two warnings: keys issued to third-party clients are relatively easy to compromise, and you should not rely on keys alone to protect sensitive, critical or high-value resources. OWASP also says keys should not appear in the URL, and Google’s docs note that a key sent as a query parameter is exposed to theft through URL scans. Google Cloud on why and when to use API keys covers the provider’s view in full. Issuing keys to the customers of an API you build yourself is a different job, covered in API authentication best practices.
What is an API key used for, and why you need one
An API key is used to tell a provider which account a request belongs to, so the provider can allow it, limit it and bill it. You need one whenever your app calls a service that meters or restricts access, such as a model provider, a payment provider or a maps API.
The purpose of an API key, in Google’s terms, is project identification and project authorization: which project is calling, and whether that project has been granted access to the API and has enabled it. Google also uses the key to tie each request to a project for billing and quota purposes. So the reason you need an API key is metering: the service has to know whose account pays for the call. Your own backend is different: calls from your app’s pages to your own server should run on your users’ logins, not on a provider key.
When a builder’s setup screen asks what the API key is, I read that as the secret key from the provider’s dashboard: paste it into the builder’s secrets panel, never into the chat. What to do with an API key once you have one is the six steps in the section on obtaining one, further down.
An API key example: what one looks like, and how keys are named
An API key example looks like a prefix followed by a long run of random characters. The prefix often names the provider and the kind of key: a publishable key meant for the browser or a secret key meant for the server. Treat any key without a documented public role as secret.
Here is one in the shape Stripe documents, with the random part replaced so nobody can use it: sk_test_EXAMPLE_NOT_A_REAL_KEY. Every key on this page is fake in the same visible way, because readers copy examples and scanners flag anything that looks live.
| Provider | Prefix | What the prefix tells you | Public or secret |
|---|---|---|---|
| Stripe | pk_test_, pk_live_ | Publishable key, sandbox or live | Public: Stripe says you can include it in front-end code |
| Stripe | sk_test_, sk_live_ | Secret key, unrestricted permissions on all Stripe APIs | Secret |
| Stripe | rk_test_, rk_live_ | Restricted key, with permissions you control | Secret |
| Supabase | sb_publishable_ | Publishable key | Public: reaches only what Row Level Security allows |
| Supabase | sb_secret_ | Secret key, full access that bypasses Row Level Security | Secret |
| Supabase | anon, service_role (long-lived JWTs) | The legacy versions of the publishable and secret keys | anon public, service_role secret |
| OpenAI | sk-, sk-admin- | OpenAI’s docs show sk- for a standard API key and sk-admin- for an admin API key | Secret: never in client-side code such as browsers or apps |
None named; Google’s own example string starts AIza | Google describes the key as an encrypted string | Typically accessible to clients, so limit it with restrictions |
The lists are kept current in Stripe’s API keys documentation and Supabase’s API keys guide; Supabase says it is deprecating the anon and service_role keys by the end of 2026. Recognizable formats help after a leak too: GitHub’s supported secret scanning patterns include secrets tied to a specific service provider, such as AWS, Azure and Stripe, and scanning runs automatically for free on public repositories. Checking your own repository is covered in secret scanning.
For an API key name example, my working rule is to name the variable after the provider and the kind, such as STRIPE_SECRET_KEY, and to name the key in the provider’s dashboard after the app and the environment that use it, such as billing-app production. When one leaks or breaks, the name tells you where it was used without opening any code. Stripe’s dashboard also has a note field for recording where you saved a key.
What it means in practice for a small SaaS: the five keys a typical AI-built app holds
A typical AI-built app holds five keys: the model provider’s, the payment provider’s secret key, the database’s service key, the email provider’s, and a public maps key. A stranger holding one of the first four can spend your money, read customer records, change any row or send mail as you, depending on which one.
They are the same five that the invalid-key guide, linked in the section on finding a key, works through: AI, database, payments, maps and email.
| Key | What a stranger can do with it | Where it must live |
|---|---|---|
| Model provider key (OpenAI) | Make model calls billed to your account (my reading; OpenAI calls the key a secret) | On the server, loaded from an environment variable or a key management service |
Payment secret key (Stripe sk_) | Use unrestricted permissions on all Stripe APIs; Stripe says a fraudulent actor with it can harm your business | On the server, in a secrets vault, or an environment variable where the platform has no vault |
| Database secret or service role key (Supabase) | Reach all of the project’s data, bypassing every Row Level Security policy | Backend components only; never a browser, a shipped app or source control |
| Email key (Resend) | With full access: create, delete, get and update any resource. With sending access: send email from your account | On the server; Resend says keys must be kept confidential |
Public key (a maps key, Stripe pk_, Supabase sb_publishable_) | Only what its restrictions or your Row Level Security allow; Stripe’s publishable key cannot create charges or read account data | In the browser is fine, with restrictions set |
Each Resend key gets its permission when it is created, and only the dashboard can change it later; see Resend’s API key permissions. The rule that follows from the table is short: secret keys live on the server in environment variables, and public keys carry restrictions instead of secrecy.
Of the apps I audited in June and July 2026, 12 of the 14 AI apps had a confirmed denial-of-wallet path, where a stranger or free account can burn the owner’s paid AI or compute bill without limit. That group was selected for audit rather than drawn at random, so the count describes it and not every AI-built app. In the same audits, three of the audited apps had a real secret permanently in git history: a webhook signing secret, a live AI-provider key, and a Stripe test key with its webhook secret.
One browser-only app I audited loaded its paid AI provider key from a config file through a script tag, and keeping that file out of git did not help, because the live page has to serve it. Anyone could read the key and spend on the owner’s account; the full story is the spam classifier that put its billing key in every visitor’s browser. The lesson I take from it: a key does not know whose browser it is in, so whoever can read it is treated as the owner.
Which keys may sit in the browser at all is covered in API keys exposed on frontend code. Limiting what a stolen key can spend is covered in how to cap monthly usage on a metered API. A key you think has already leaked is an incident with its own steps: what to do when an API key leaks.
What it is not: API key and secret, client secret, token and password
An API key is not a client secret, a token or a password. A key is sent on every call and usually lives until someone revokes it. A client secret is used by an OAuth app to obtain tokens. A token is issued after authentication and expires. What they share: whoever holds one can act with it.
| Term | Who holds it | What it proves | How long it lives |
|---|---|---|---|
| API key | Your server, or the browser for a public key | That the call comes from this project | Until it is revoked; Google says a stolen key has no expiration, and Stripe lets you expire or rotate one |
| API key and secret pair | Your server | The key identifies the caller; the secret authorizes higher privilege operations | Not stated in Picsart’s docs |
| Client secret | A confidential OAuth client, on a server | The client’s identity when it asks the token endpoint for tokens | Not stated in RFC 6749 |
| Access token | The app, after authentication | An authorization with specific scopes | A lifetime set when it is issued |
| Password | A person | That person, at login | Until the person changes it (my reading) |
API key vs client secret, in one line as I read the standard: a key goes out on every call, and a client secret is used to get tokens. RFC 6749, the OAuth 2.0 standard, says confidential clients must authenticate with the authorization server when they make requests to the token endpoint, and describes an access token as a string denoting a specific scope, lifetime and other access attributes.
Some providers issue a key and a secret as a pair. Where they do, the secret is the half to guard harder: Picsart’s docs call secrets more sensitive than API keys because they allow higher privilege operations. An API secret key, at some providers, is the key itself under another name: Stripe calls its server-side sk_ keys secret keys, and each one is an API key that must stay on the server, not a separate kind of credential. How a key compares with a password is answered in the FAQ below.
How to obtain an API key: how to get API keys and use them without leaking them
An API key is obtained in six steps at most providers, by my working rule: sign in with a company account, create a key for one app and one environment, restrict it, copy it once, store it as a server-side environment variable, and send it from the server in the header the docs name.
- 01 Sign in to the provider with an account the company owns, not a contractor's personal login.
- 02 Create a key for one app and one environment, and give it a name that says which.
- 03 Restrict it wherever the provider allows: which APIs, which websites or IP addresses, which permissions.
- 04 Copy the value once, straight into your secret store, because some providers never show it again.
- 05 Store it as a server-side environment variable, never in code, a prompt, a chat or a screenshot.
- 06 Send it from the server, in the header the provider's docs name.
Step 1 matters most when someone else built the app; the case where the provider account is theirs is covered in when a developer owns our hosting account. Step 2 keeps a test mistake out of production, and the risks of sharing one key across environments are in environment variables security risk.
Step 3 looks different at each provider. Google offers API restrictions and application restrictions by website, IP address or app, and recommends setting both. Stripe offers restricted keys with permissions you control, and access policies, which replaced its IP address restrictions. Google API key security rests mostly on this step, because Google calls its keys typically accessible to clients.
Step 4 is literal. Stripe displays a live-mode secret key one time and you can’t reveal it later, and Resend says you cannot view an API key value after it has been created. For step 5, OpenAI tells you to load keys from an environment variable or a key management service on the server, and Stripe points to your platform’s secrets vault first. Which setting or file that variable goes into on each kind of host is in where an environment variable belongs. Setting up an API key inside the app is steps 5 and 6 together: set it as a server variable, then have the server code read it by name.
To get an API key, you press the create button in the provider’s own dashboard; the provider generates the API key string at that moment. A site offering a free API key generator is not where a working key comes from: the only key that works is the one the provider issues, and I treat any string such a site shows you as one it has already seen. Nothing about making an API key for a third-party service needs code, and generating keys for callers of your own API belongs to the API authentication page linked above. To use the API key once it is stored, send it in the header from the four steps at the top of this page.
How to open an API key you made earlier depends on the provider. If the dashboard will not show the value again, create a new one, move the app to it and retire the old one; how saved keys go stale inside builders is covered in the invalid-key guide linked in the next section. Each provider’s own docs walk through its dashboard screen by screen, so this page does not repeat them.
How to find your API key when someone else created it
Finding an API key someone else created means looking in two places. The provider’s dashboard lists your keys, usually masked. Your app keeps its copy in the host’s environment variables or the builder’s secrets panel. If only a former developer can open the dashboard, fix account ownership first.
On the provider’s side, OpenAI’s docs send you to your API keys page, Google lists keys on the Credentials page of the Cloud console, and Supabase keeps every key, legacy or not, under Settings > API Keys. Whether the full value can be shown again differs: Stripe, for example, lets you reveal only the live keys it created for you, while sandbox keys stay visible. To know which API key is yours, sign in to that dashboard as the account owner, since access to an API key runs through the provider account that created it.
| Where the app keeps its copy | How to look | What you will see |
|---|---|---|
| The host’s environment variables page | The project’s settings in the hosting dashboard | Variable names, with values often hidden |
| The AI builder’s secrets panel | The builder’s secrets or settings area | The names you saved; some builders never show the value again |
A .env file on a developer’s laptop | Ask the developer; a correctly set up repository does not contain it | The full value in plain text |
| The code or the browser bundle, when something went wrong | Search the repository, or open the browser’s developer tools on the live page | A key in plain view, which means it has to move to the server |
When the dashboard itself belongs to a former developer, the developer-owned account page linked above is the place to start. Where Lovable, Replit and Base44 keep keys, and how a saved key goes stale, is in which of your keys broke, and where it lives.
How to check an API key safely, without an online API key checker
An API key is checked safely without an online API key checker: look at the key’s recent use in the provider’s own dashboard, where it shows one, then send one read-only request from your own machine and read the status code. Pasting a key into a checker website hands it to a stranger.
The request below verifies an API key at Stripe with a sandbox secret key, the kind that starts sk_test_; other providers each document their own read-only call.
- 01 Open the provider's own dashboard, find the key, and look at its recent activity where the dashboard shows it. Keep a screenshot of the page.
- 02 From your own machine, send one read-only request with the key in the documented header and read the status code. Run it once with the right key and once with a deliberately wrong one, keep both results, then delete the command from your terminal history.
- 03 If the key has to be replaced, rotate it so the old and new keys overlap and nothing goes down.
For step 1, Resend’s dashboard shows the last time each key was used, and Stripe opens the request logs for any key from its API keys page. For step 2, this is the Stripe request, with a placeholder where your sandbox key goes:
curl https://api.stripe.com/v1/balance -u "sk_test_EXAMPLE_NOT_A_REAL_KEY:"The call only retrieves the account balance for the key that made it. The -u flag sends the key as the HTTP Basic Auth username, which is how Stripe authenticates, and in Stripe’s words “The colon prevents curl from asking for a password.” A good key returns a balance object; for a missing or wrong key, Stripe documents a 401 with “No valid API key provided.” For step 3, the order of operations is in how to rotate API keys safely.
Testing an API key this way keeps it between your machine and the provider that issued it. An online checker receives the key, and you cannot verify what that site keeps. When a key fails the test and you need to know why your API key is not working, the invalid-key guide linked above works through it key by key, with each vendor’s own error words. A message saying the API key is missing usually means the variable is not set in the environment where the app runs, which the environment variables article linked above covers, and a message saying an API key is required means the same thing.
Where the sprint fits
In the Production Hardening Sprint, the keys on this page fall under area 2 of the scope, secrets, keys and configuration, whose nine deliverables include these six. Deliverable 2.1 removes all private secrets from frontend code and downloadable bundles, relocating their use to server-side code. Then 2.2 scans Git history for committed secrets and rotates every exposed credential found. We verify service-role and administrative keys are used exclusively in protected server environments (2.3). Development, staging, and production variables, databases, and keys are separated, and the configuration inventory is documented (2.4). Deliverable 2.6 documents how to rotate each key, update its dependents, verify the change, and recover from a failed rotation. For 2.8, provider account ownership, the check is an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed. Hosting, paid tools and API usage are paid through your accounts, and we explain any required costs before enabling them. Each deliverable’s wording and its check are in the published scope.
Common questions about API keys
Is an API key just a password?
No. An API key identifies a project, not a person: Google’s docs say API keys identify the calling project. A key has no username and no login step, and your app sends it with every call. It shares one property with a password, which is that anyone holding it gets in.
Is API key free or paid?
In my reading, you pay for the usage a key authorizes, not for the key itself. At Google, billing is enabled per project and you are billed only for usage of billable APIs: some Google APIs charge for usage and need billing enabled before you can use them, and some allow free usage up to a courtesy limit. I read free tiers the same way: they still need a key, because the key is how the provider counts your free calls. What a key costs when somebody else is holding it is the subject of the usage caps guide linked in the five keys section.
How do I activate an API key?
In my reading of the providers’ docs, most keys work as soon as they are created. When a Google key does not, check the API and the billing: the key’s project must have the API enabled, and enabling an API also enables billing for it if billing is on for the project. An API restriction can only name an API that is already enabled for the project, so enable first, then restrict.
How do I find my API key in Google?
Open the Google Cloud console project that owns the key, go to APIs & services, then Credentials; the keys for that project are listed there. If the key is not there, check that you are in the right project and signed in with the right account. Google Cloud’s page on managing API keys covers creating, restricting and rotating them.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase