Adding Bearer Token, Basic, and API-Key Auth to Unreal HTTP Calls

The problem: a protected endpoint that keeps returning 401

Almost every real web API behind a login wants you to prove who you are before it hands back data, and in Unreal that usually means setting the HTTP request authorization header. Get the bearer token wrong, forget to Base64-encode a Basic credential, or send your API key under the header name the service doesn't expect, and the call comes back as a 401 or 403 with no useful response body to debug from.

Doing this by hand in Blueprint is fiddly. The engine's HTTP module is C++-first, so you end up promoting variables, building string maps, and concatenating 'Bearer ' onto a token while hoping the spacing is right. EasyHTTP removes that step. It is a Blueprint-friendly HTTP plugin that wraps the engine's HTTP module and ships dedicated helper builders for the common authentication schemes, so the header is constructed correctly for you.

This tutorial walks through all four auth schemes EasyHTTP supports, with the exact nodes to wire up. Everything here uses the plugin's FEasyHTTPRequestOptions struct and the 'Make Options With...' builders, which you feed into an 'Easy HTTP Request' node or one of the async request nodes.

The four auth schemes EasyHTTP supports

EasyHTTP models authentication with the EEasyHTTPAuthType enum, which has five values: None, Basic, Bearer, ApiKey, and Custom. None is the default and sends no auth header at all. The other four each correspond to a way of putting credentials on the request, and three of them have a one-shot builder node that returns a fully populated FEasyHTTPRequestOptions struct.

The three builders are 'Make Options With Bearer Token' (MakeOptionsWithBearerToken), 'Make Options With Basic Auth' (MakeOptionsWithBasicAuth), and 'Make Options With Api Key' (MakeOptionsWithApiKey). Each one starts from sensible defaults and sets the Authentication field on the options for you, so you do not have to understand the internals of the struct to get a working authenticated request.

The fifth scheme, Custom, is for cases the builders don't cover, such as an HMAC-signed header. There you build a plain options struct and add your own header by hand with 'Add Header To Options'. We'll cover that at the end. In every case the Options pin on the request node is under Advanced Display, so click the small arrow at the bottom of the node to reveal it before you connect your builder output.

Bearer token auth for JWT and OAuth

Bearer is the scheme you want for JWT access tokens and OAuth-style APIs. It produces an 'Authorization: Bearer ...' header, where the value is the token string exactly as the auth server gave it to you. This is the unreal engine http request authorization header bearer token pattern most modern REST services expect.

1. In your Blueprint graph, right-click and add the 'Make Options With Bearer Token' node.

2. Connect the access token you received from your login or OAuth flow to its Token input. Do not prepend 'Bearer ' yourself; the builder adds the scheme prefix, so you pass only the raw token.

3. Add an 'Easy HTTP Request' node (or 'Async HTTP Request' if you want separate On Success and On Failure execution pins), set the URL to your protected endpoint, and choose the Method from the dropdown.

4. Expand the node's Advanced Display and connect the FEasyHTTPRequestOptions output of the builder into the request's Options pin.

5. Handle the result by breaking the FEasyHTTPResponse: check bSuccess, read StatusCode, and parse Content. For JSON, feed Content into the engine's built-in 'Json String to Struct' to fill a USTRUCT.

Because the token is just a string, this also covers short-lived tokens: when one expires, rebuild the options with the refreshed token before your next call. If you need extra headers alongside the bearer token, chain 'Add Header To Options' off the builder output before it reaches the request node.

Basic auth, and why the docs warn you to use HTTPS

Basic authentication sends a username and password with each request. EasyHTTP's 'Make Options With Basic Auth' node takes a Username and a Password and Base64-encodes the 'user:pass' pair into the Authorization header for you, so you never touch the encoding step manually.

1. Add 'Make Options With Basic Auth' and wire your username and password strings to its inputs.

2. Connect its FEasyHTTPRequestOptions output into the Options pin of your request node, exactly as with the bearer flow.

The important caveat is honesty about what Base64 is: it is an encoding, not encryption. The EasyHTTP docs explicitly warn that Basic Auth is reversible and that you should always use HTTPS. Anyone who can read the request can trivially decode the credentials back to plain text, so the only thing protecting them in transit is the TLS layer. Always point Basic Auth requests at an https:// URL, never plain http://, and never at the built-in test server, which is HTTP-only and meant for development. EasyHTTP supports HTTPS through the engine's SSL/TLS, so a normal https:// endpoint just works.

If a service offers both Basic and token auth, prefer the token. Basic is convenient for quick internal tooling, but a long-lived username and password on every request is a larger blast radius than a revocable access token.

API-key auth and common header names

Many APIs authenticate with a single secret key sent in a header rather than a username, password, or token. EasyHTTP's 'Make Options With Api Key' node covers this with the ApiKey auth type. You supply the key value and the header name the service expects, and the builder places the key under that header.

The header name matters because there is no single standard. Some services read the key from 'X-API-Key', others from 'Authorization', others from a vendor-specific name like 'Api-Key' or 'X-Api-Token'. Check your provider's documentation for the exact spelling and capitalisation, then pass that as the header name so the request matches what the server is looking for.

1. Add 'Make Options With Api Key' and set the key value to your secret.

2. Set the header-name input to the exact name the API documents, for example 'X-API-Key'.

3. Wire the options into your request node's Options pin and handle the response as usual.

If the API wants the key plus other fixed headers, build the options with the key first and then chain 'Add Header To Options' (or 'Make Header') for each extra header before the request node.

Custom header auth for HMAC signatures and anything else

Some APIs don't fit Bearer, Basic, or a single API key. HMAC-signed requests are the common example: you compute a signature over the request and send it, often alongside a timestamp and a key id, under one or more custom headers. That is what the Custom auth type and manual header building are for.

Rather than using an auth builder, start from 'Make Default Options' to get a baseline FEasyHTTPRequestOptions struct. Then chain 'Add Header To Options' once per header you need to attach: your signature header, any timestamp or nonce header, and any key-identifier header your scheme requires. Each call adds to the AdditionalHeaders on the options, so you can stack as many as the API demands.

1. Add 'Make Default Options'.

2. For each custom header, add an 'Add Header To Options' node and set the header name and value; you can compute the value (such as an HMAC signature) elsewhere in your graph and feed it in.

3. Connect the final options output into the request node's Options pin and send.

This same manual approach is how you'd add one-off headers on top of any of the builder-based schemes, since the builders return a normal options struct that 'Add Header To Options' is happy to extend. EasyHTTP does not ship built-in certificate pinning, so if your security model needs pinning, plan for it outside the plugin.

Testing auth locally before you ship

Before pointing an authenticated call at a live backend, it is worth confirming your graph wiring is correct. EasyHTTP includes a local test server you can start from Blueprint with 'Start Local Test Server' (default port 8080). Send your request at http://localhost:8080/ and inspect exactly what arrived with 'Get Last Server Request', which lets you confirm the Authorization or API-key header is present and formatted as you expect.

Use this only for development. The test server is HTTP-only, so do not send real Basic credentials or production tokens to it; build the wiring against it, then switch the URL to your real https:// endpoint once you can see the header is correct. Call 'Stop All Test Servers' on End Play so you don't leave a listener running.

From here the natural next step is parsing what comes back: break the FEasyHTTPResponse, check IsResponseSuccessful, and turn the JSON Content into a struct. With the auth header handled correctly, the rest of the integration is just data.

EasyHTTP authentication schemes at a glance

All values are from the EasyHTTP plugin's auth builders and EEasyHTTPAuthType enum.

FAQ