What Is an API Key? Meaning, a Real Request, and How to Keep One Safe

An API (application programming interface) is a set of URLs a program can call to get data or trigger an action. An API key is the credential that goes with those calls: a long random string that the provider generates for your account and stores on its side. When a request arrives, the server reads the key, finds the account it belongs to, checks that the account may use this endpoint and has quota or credit left, and only then does the work. Because every request carries the key, the provider can meter usage per account, enforce rate limits, and bill the right customer.

What a key is not. A key does not identify a human being. IBM's explainer puts it as authenticating the application rather than the individual user, and OWASP's REST Security Cheat Sheet warns: "Do not rely exclusively on API keys to protect sensitive, critical or high-value resources." A key also does not encrypt anything; HTTPS does that. The key is closer to a long, unguessable account password that a program sends instead of a person typing it.

Why providers use them. Keys are cheap to issue and simple to check, which makes them the default for server-to-server APIs. OWASP lists the benefits plainly: public REST services without access control "run the risk of being farmed", leading to excessive bills, and requiring a key on every request lets the provider rate-limit, return 429 Too Many Requests, and revoke a client that breaks the rules.

What one looks like. Many providers add a readable prefix so the key type is obvious at a glance, which also helps scanners spot leaked keys. Stripe documents the clearest scheme: pk_test_ and pk_live_ for publishable keys, sk_test_ and sk_live_ for secret keys, and rk_ for restricted keys. Other providers use their own prefixes for the same reason. The rest of the string is random and carries no meaning you can decode.

Here is the full life of one request against TwitterAPI.io, which authenticates with an X-API-Key header. We sent this request with our own key (the key itself never appears in this page, our logs or the study files) and recorded the status and the shape of the response.

With a valid key. GET https://api.twitterapi.io/twitter/user/info?userName=OpenAI with X-API-Key: <key> returned HTTP 200 and a body with three top-level fields: status set to "success", msg set to "success", and data, a profile object with 25 fields such as userName, followers, statusesCount, createdAt, isBlueVerified and canDm. The call cost 18 credits ($0.00018), the documented price of one profile.

Without a key, or with a wrong one. We did not send these two requests: our study client always attaches a key, and we chose not to send an unauthenticated request outside it. The bodies below are the ones documented at docs.twitterapi.io/errors, fetched this session, and the authentication page states the causes: 403 when "No x-api-key header was sent", 401 when "The key is wrong or has been reset."

401 or 403 for a missing key? Services disagree, and both are defensible. OWASP's cheat sheet maps 401 to "Wrong or no authentication ID/password provided" and 403 to an authenticated caller without permission; TwitterAPI.io instead returns 403 for a missing header and 401 for a bad key, so your client can tell "I forgot to send it" from "I sent the wrong one". Read the provider's error page rather than assuming, and log the body: the message field usually names the fix.

The same request in curl is shown below. Note that the key comes from an environment variable, so it never lands in your shell history or a script you might commit.

These four terms get mixed up because they overlap. Two describe what the credential is (API key, access token), one describes how a token is obtained (OAuth), and one describes how a credential is sent and who may use it (bearer).

Bearer is a property, not a kind of key. RFC 6750 defines a bearer token as "a security token with the property that any party in possession of the token" can use it, without proving possession of any cryptographic key, and shows the header form Authorization: Bearer mF_9.B5f-4.1JqM. Most API keys are bearer credentials in exactly this sense, which is why some services accept the same key in either header. TwitterAPI.io's authentication page, for example, accepts Authorization: Bearer <key> as well as x-api-key, with x-api-key taking precedence when both are sent.

When you need OAuth instead of a key. A key is enough when your program acts as itself: reading public data, calling a model, charging a card on your own merchant account. You need OAuth when the program acts on behalf of another person's account, for example posting from a user's X account through the official X API, which requires OAuth 1.0a or OAuth 2.0 user context. The OAuth flow returns an access token that is scoped to what that user approved and expires; the user can revoke it without touching your app's own credentials.

Keys and secrets in pairs. Some providers issue a key plus a secret (the official X API's consumer key and secret, AWS's access key ID and secret access key). The first half identifies, the second signs or proves. Treat both halves as secret unless the provider says otherwise; Stripe's publishable pk_ key is the rare documented exception that is safe in front-end code because it cannot perform sensitive operations.

There are three places a key can travel, and the primary sources agree on the order of preference.

Header (preferred). A custom header such as X-API-Key, or the standard Authorization header with the Bearer scheme. OWASP: "In GET requests sensitive data should be transferred in an HTTP Header." Headers are not stored in browser history and are not usually written to access logs.

Query string (fallback only). Some APIs accept ?key=... or ?api_key=.... Google Cloud's documentation prefers the x-goog-api-key header and says that if you cannot use it you can use the key query parameter, but warns that this "includes your API key in the URL, exposing your key to theft through URL scans." OWASP is stricter: "Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs." RFC 6750 says the same of bearer tokens.

Body. For POST and PUT requests a credential can go in the JSON body, though few APIs ask for it there; the header remains the norm.

Header names are case-insensitive in HTTP, so X-API-Key, x-api-key and X-Api-Key are the same header on the wire. For the details of setting it in curl, Postman, Python and Node, see the x-api-key-header guide linked below.

To see what actually happens with API keys in practice, we collected recent public posts on X that contain "api key", "api keys" or the spellings apikey, api_key and api-key, through our own search endpoint. After removing duplicates across the four searches the sample holds 796 posts from 665 distinct accounts, 31.9% of them replies. The three Latest-order searches each stopped returning results after 7 to 11 hours of posts (360 posts in 11.0 hours for "api key" alone), so the phrase appears on X at least roughly 30 times an hour in English.

AI tooling dominates. 40.6% of posts sit in an AI agent, LLM, MCP or coding-assistant context, and 30.8% name at least one AI model provider. Anthropic or Claude appears in 18.1% of posts, OpenAI or ChatGPT in 13.7%, Google or Gemini in 8.8%, xAI or Grok in 3.4% and OpenRouter in 1.6%. Older key-heavy platforms trail: GitHub 5.3%, AWS 1.4%, Stripe 1.1%. Two thirds of posts (66.2%) name none of these services.

Keys are money. About one post in four (26.3%) talks about billing, credits or spend in the same breath as a key, and 13.4% discuss a leaked, exposed or stolen key: breach notices, warnings about keys pasted into public repositories, and stories of unexpected charges. A further 1.3% (10 posts) openly advertise or discuss buying and selling AI provider keys. That market is the practical reason a leaked key matters: whoever holds a bearer credential can spend against your account until you revoke it.

Nobody pasted a live-looking key. We checked every post for strings shaped like real secrets (Anthropic-style sk-ant-, OpenAI-style sk-, Google AIza, GitHub ghp_, xAI xai-, AWS AKIA and Stripe sk_live_ patterns at realistic length). None of the 796 posts contained one; we counted by pattern only and did not store or test anything. Keys leak through code repositories, logs and front-end bundles far more than through posts, which is what the next section is about.

Errors are rarely the topic. Only 1.4% of posts mention a 401, a 403 or an invalid key. People post about getting keys, paying for them and losing them much more than about authentication failing, and leak posts drew slightly more views at the median (63) than other posts (56).

The service mix explains the leak share. AI model keys are prepaid or billed by usage with high limits, and a stolen one turns straight into compute someone else pays for. In our sample, the AI providers together (30.8% of posts) outnumber GitHub, AWS and Stripe combined (7.8%).

Bring your own key. 2.8% of posts mention BYOK: tools that ask you to paste your own provider key so their app calls the model on your account. It is convenient, and it means you are trusting that tool's storage with a bearer credential. Prefer tools that keep the key locally, and give each one its own key so you can revoke it alone.

What the official guidance says about spend. Google's page on using API keys states that "publicly exposing your API keys can lead to unexpected charges on your account." Set a spend limit or budget alert where the provider offers one, so a leaked key has a ceiling.

Every primary source we checked gives the same short list. Stripe's key documentation is the most concrete, so its wording anchors the rules below.

Keep it on the server. A key in front-end JavaScript, a mobile app bundle or a browser extension is public: anyone can open developer tools and read it. Call the API from your back end (or a serverless function) and have the browser call your back end. The only keys designed for the browser are the ones the provider says are safe there, such as Stripe's publishable pk_ key, which "can't perform sensitive operations".

Never commit it. Stripe: "Don't put keys in source code or configuration files checked into version control." Load the key from an environment variable or a secrets manager, keep .env files in .gitignore, and turn on secret scanning. GitHub documents that secret scanning "scans your entire Git history on all branches" and that it "runs automatically for free" on public repositories.

One key per app and environment. Separate keys for development, staging and production, and for each tool or teammate, mean you can revoke one without breaking the others, and your usage logs show which caller did what. IBM's explainer and Stripe's restricted-key model both push in this direction: give each key only the permissions its job needs.

Restrict where it works. Many providers let you limit a key to certain IP addresses, referrers, apps or APIs (Stripe calls these access policies). A restricted key that leaks is worth far less to whoever finds it.

Rotate on any suspicion, and on a schedule. Rotation means issuing a new key, moving your code to it, then revoking the old one. Stripe's dashboard keeps both keys working "for up to 7 days" so you can switch without downtime; rotate immediately when a key may have been exposed and when someone with access leaves. On TwitterAPI.io you reset the key in the dashboard, after which the old one returns the 401 shown above.

Never share it over chat or email, and never paste it into a post, a support ticket or an AI chat. If you must show a request in public, write <key> or YOUR_API_KEY in its place.

The details differ per provider, but nearly every service follows the same five steps.

1. Create an account on the provider's developer site or console. Some require a verified email or a payment method before issuing a key.

2. Create the key in the dashboard, give it a descriptive name ("prod-backend", "local-dev"), and copy it once. Several providers, Stripe among them, show a secret key only once at creation.

3. Store it in an environment variable or secrets manager, never in the code.

4. Send it on each request in the header the documentation names, over HTTPS.

5. Watch usage in the dashboard and set alerts or limits, then rotate as described above.

For TwitterAPI.io the key is shown on the dashboard homepage after you sign in, and reading public X data needs no X account and no developer-portal approval. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days); purchased credits never expire. Requests are limited to 0.2 per second before the first payment and 20 per second once paid.

What the data behind a key costs depends on the provider's rate card. On TwitterAPI.io tweet endpoints bill 15 credits per tweet returned, $0.15 per 1,000 tweets, and profiles 18 credits each, $0.18 per 1,000. The official X API's pay-per-usage rate card (docs.x.com/x-api/getting-started/pricing) lists $0.005 per post read and $0.010 per user read, which is $5 per 1,000 posts, about 33 times the $0.15 per 1,000 tweets above. For the provider-specific walkthroughs, see the X, Claude, OpenAI and Grok key guides linked below.

When a key that should work does not, it is almost always one of the following.

Sending the key in the wrong header. If a service expects X-API-Key and you send Authorization: Bearer, or the reverse, you get the missing-key error even though the key is right. Check the exact header name in the docs; some services accept both.

Stray whitespace or quotes. Copying a key from a dashboard can pick up a trailing newline or space, and shell quoting can wrap it in literal quotes. Strip the value when you load it (os.environ["TWITTERAPI_KEY"].strip()).

Using a test key in production, or the reverse. Stripe's sk_test_ and sk_live_ keys work only in their own mode, and objects in one mode are not visible in the other. Other providers separate projects or organizations the same way.

A reset key still in some deployment. After rotation, every place the old key lived (CI secrets, a teammate's laptop, a cron server) starts returning 401. Keep a list of where each key is deployed; Stripe's dashboard even has a note field for exactly that.

Out of credit, not unauthorized. A valid key on an account with no balance returns a different error (402 on TwitterAPI.io). Read the message before regenerating a key that was never the problem.

Treating a key as user authentication. A key proves which account is calling, not which human is using your app. If your app has its own users, authenticate them separately and keep the provider key on your server.

Question. When people post publicly on X about API keys, which services do they name, what are they doing (getting, paying for, leaking, rotating, or failing to use a key), and does any post contain a string shaped like a live secret? Plus a first-hand check of one authenticated request.

Queries. Four searches through TwitterAPI.io's /twitter/tweet/advanced_search, English, retweets excluded: "api key" (Latest and Top order), "api keys" (Latest) and apikey OR api_key OR "api-key" (Latest), newest first, following next_cursor until results ran out or the page cap. The three Latest searches ran out after 7.1 to 11.0 hours of posts; the Top search reaches further back. One /twitter/user/info call for OpenAI supplied the 200 example.

Sample. 1,112 posts returned, 796 unique after de-duplication, from 665 accounts. 62 requests in total; the study cost about $0.17 in credits. Collected in 2026.

Method. Services and themes are keyword matches on the post text (one post can match several themes), so a post about "Claude" that never names Anthropic still counts for Anthropic / Claude, and an ironic post counts the same as a sincere one. Key-shaped strings were detected by documented prefix patterns at realistic lengths and only counted.

What the sample cannot show. It covers English-language posts from a few hours of one period plus a Top-ranked slice; it says nothing about how often keys leak in code repositories, and the 401 and 403 bodies on this page are documented responses, not captured ones.

Privacy. Aggregates only. Search authors are private individuals, so raw pages were kept outside the repository and deleted after analysis; the published sample holds de-identified rows with no ids, links, text or handles. No key-shaped string was recorded or tested.