Skip to Main
View .mdAsk ClaudeAsk ChatGPT

Think of an API as a hotel with a front desk. Anyone can walk up and ask a question, but to get into a room you need a keycard. Authentication is the keycard: a credential you present with each request that proves the API provider gave you access. Without it, the provider has no way to know who is asking, what they’re allowed to see, or whom to bill for the usage.

This page explains the concepts. When you’re ready to configure an API, the “See it in practice” links at the bottom walk through each type step by step.

Why APIs require credentials

An API provider needs to answer three questions about every incoming request:

  1. Who is this? — so private data goes only to its owner.
  2. What are they allowed to do? — read-only vs. write access, free vs. paid plans.
  3. How much are they using? — rate limits and billing are tracked per credential.

That’s why almost every real-world API hands you a credential when you sign up — a token, a key, or a username and password — and rejects requests that arrive without it, usually with an HTTP 401 Unauthorized response.

What each type sends on the wire

However the credential is labeled in a provider’s dashboard, it travels in one of a few standard places inside the HTTP request. Here is the same request shown with each of the three most common schemes:

flowchart LR
    R["GET /v2/reports<br>Host: api.example.com"] --> H[Request headers]
    R --> Q[URL query string]
    H --> BT["Authorization: Bearer &lt;token&gt;<br>(Bearer Token)"]
    H --> AK["X-API-Key: &lt;key&gt;<br>(API Key, header)"]
    H --> BA["Authorization: Basic &lt;base64 of user:pass&gt;<br>(Basic Auth)"]
    Q --> QS["?api_key=&lt;key&gt;<br>(API Key, query string)"]

Bearer Token

The credential is a single opaque string (“token”). It travels in the standard Authorization header, prefixed with the word Bearer:

Authorization: Bearer hxc_example_token_123

“Bearer” means exactly what it says: whoever bears (holds) the token gets access. That’s why tokens must be kept secret. Most modern APIs — including those that issue tokens through OAuth flows — use this scheme.

API Key

Also a single secret string, but sent in a place and under a name the provider chooses. There is no single standard, which is why the two look-ups you need from the provider docs are the name and the location:

  • Header — a custom header such as X-API-Key: <key>.
  • Query string — appended to the URL, such as ?api_key=<key>.

Header placement is preferable when the provider offers both, because query strings end up in server logs and browser history.

Basic Auth

The oldest scheme: a username and password joined with a colon, encoded with base64, and sent in the Authorization header:

Authorization: Basic ZGVtb191c2VyOmh4Y19leGFtcGxlX3Rva2VuXzEyMw==

Important: base64 is an encoding, not encryption — anyone who sees that header can decode it back to the username and password. Basic Auth is only safe over HTTPS. Many APIs use it with an API key as the username and an empty or fixed password.

How to find out which one your API uses

Read the provider’s documentation — look for a page titled “Authentication”, “Authorization”, or “Getting started”. You’re hunting for two things:

  1. The scheme: does the example request show Authorization: Bearer ..., a custom header like X-API-Key, a query parameter, or a username/password pair?
  2. Where to get the credential: usually a dashboard page called “API keys”, “Tokens”, or “Developer settings”.

A provider’s cURL example gives it away instantly. -H "Authorization: Bearer ..." means Bearer Token; -H "X-Something: ..." means API Key in a header; -u user:pass means Basic Auth; a key inside the URL means API Key in the query string.

HuxxConnect covers all three schemes out of the box, plus a Custom (Hook) type for anything unusual — see Authentication types for the full list. The secret fields — token, API key, password — are encrypted before they are stored; how that works is covered in Encryption tiers. One exception: the Basic Auth Username field is stored in plaintext and is kept in configuration exports even when credentials are stripped. If your provider uses an API key as the username, don’t put the key there directly — reference it from wp-config.php or an environment variable instead, as shown in Store credentials outside the database.

See it in practice