---
title: Understanding API Authentication
slug: understanding-authentication
type: explanation
plugin: huxx-connect
summary: Why APIs require credentials, what Bearer Token, API Key, and Basic Auth actually send on the wire, and how to find out which one your API expects.
keywords: [authentication, credentials, bearer token, api key, basic auth]
version_added: 1.2.5
version_updated: 1.2.5
level: beginner
related: [authenticate-with-a-bearer-token, authenticate-with-an-api-key, authenticate-with-basic-auth, authentication-types, encryption-tiers]
---

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](/docs/connect/explanation/what-is-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:

```mermaid
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](/docs/connect/explanation/glossary/#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](/docs/connect/reference/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](/docs/connect/explanation/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](/docs/connect/how-to/store-credentials-outside-the-database/).

## See it in practice

- [Authenticate with a Bearer Token](/docs/connect/how-to/authenticate-with-a-bearer-token/)
- [Authenticate with an API Key](/docs/connect/how-to/authenticate-with-an-api-key/)
- [Authenticate with Basic Auth](/docs/connect/how-to/authenticate-with-basic-auth/)
- [Store credentials outside the database](/docs/connect/how-to/store-credentials-outside-the-database/)