API authentication in .http files

GUI clients wrap authentication in dropdowns and helper forms — and in the end they all produce the same thing: an Authorization header on the wire. The .http format skips the wrapper. You write the header the server will see, so what you test is what your code will send. No hidden magic, nothing to un-learn when you debug with curl.

The most common scheme in modern APIs. Put the token after Bearer in the Authorization header, directly under the request line:

GET https://api.example.com/orders
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0.abc123

In practice, never paste the token inline — declare it once as a variable and reference it in every request:

@token = eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0.abc123

### List orders
GET https://api.example.com/orders
Authorization: Bearer {{token}}

### Cancel an order
DELETE https://api.example.com/orders/42
Authorization: Bearer {{token}}

Better still, keep token in a .env environment file so the committed .http file carries no secret at all — see variables & environments.

Basic auth is a base64-encoded username:password pair — and encoding it by hand is busywork. Write the credentials in plain text and let the client encode them; Karve, the VS Code REST Client, and the JetBrains HTTP Client all accept these three equivalent forms:

# colon form — encoded for you
GET https://httpbin.org/basic-auth/user/passwd
Authorization: Basic user:passwd

### space form — encoded for you
GET https://httpbin.org/basic-auth/user/passwd
Authorization: Basic user passwd

### already-encoded base64 — passed through unchanged
GET https://httpbin.org/basic-auth/user/passwd
Authorization: Basic dXNlcjpwYXNzd2Q=

All three send the identical request. Combine with variables to keep credentials in one place — the format guide shows the variable form in full.

API keys travel either in a custom header or in the query string — the provider's docs tell you which. Both are one line in a .http file:

@apiKey = sk-live-your-key-here

### Header-style key
GET https://api.example.com/reports
X-API-Key: {{apiKey}}

### Query-string key
GET https://api.example.com/weather?city=Oslo&appid={{apiKey}}

The token endpoint is itself just an HTTP request, so it belongs in your file too. A client_credentials exchange looks like this:

### Get an access token
POST https://auth.example.com/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id={{clientId}}&client_secret={{clientSecret}}

Run it, copy the access_token from the response, and drop it into your .env as the token value. Honest note: Karve v1 doesn't chain the response into the next request automatically (some ecosystem tools do) — the copy step is manual today, and the response stays one click away in Karve's history whenever you need it again.

There's deliberately no OAuth wizard or auth helper form in Karve: auth stays header-based, so your file remains portable and self-explanatory.

The rule for every scheme on this page:

• The committed .http file references {{token}} / {{apiKey}} — never a real value.
• Real values live in a .env file listed in .gitignore.
• A committed .env.example documents which keys teammates must fill in.