How to Make an HTTP Request in Unreal Engine 5 from Blueprints (No C++)

Why HTTP from Blueprints is awkward by default

Unreal Engine ships with a perfectly capable HTTP module, but it lives squarely in C++. The moment you want to fetch some JSON from a REST API, submit a leaderboard score, or pull live config at Begin Play, the stock answer is to write a new C++ class, bind a completion delegate, marshal the response, and expose the whole thing back to Blueprint yourself. For a designer-led team or a Blueprint-first project, that is a lot of boilerplate standing between you and a single GET request.

If you have searched for how to make an HTTP request in Unreal Engine from Blueprint and come away with answers that all begin with create a new C++ class, this tutorial takes the other route. EasyHTTP wraps the engine's HTTP module behind Blueprint-friendly nodes so you can call web APIs without touching C++ at all. It supports every common HTTP method, custom headers and timeouts, multiple authentication schemes, retry-on-connection-error, and progress callbacks, and it adds a built-in local test server so you can develop against a fake endpoint before your backend even exists.

This guide walks the fast path: install the plugin, fire a GET with a single node, read the response, and handle failure properly. By the end you will have a working request in the Event Graph with no C++ in sight. One thing to set expectations before you start: EasyHTTP is Windows 64-bit only, and it targets Unreal Engine 5.5, 5.6 and 5.7. There is no streaming and no WebSocket support; the full response is buffered, which is exactly what you want for ordinary REST calls.

Installing and enabling EasyHTTP

Installation is the standard plugin process. Copy the EasyHTTP folder into your project's Plugins directory (or into Engine/Plugins if you want it available across projects), then restart the editor so Unreal picks it up.

EasyHTTP is enabled by default, so once the editor restarts you should not need to flip anything on. You can confirm it is loaded under Edit > Plugins, where it appears in the Networking category. If for any reason it is not ticked, enable it there and restart once more.

The plugin is a single Runtime module with no external or third-party dependencies. It leans only on standard engine modules such as HTTP, Json and Sockets, so there is nothing extra to download and nothing to configure before your first request. If you want a feel for the API before wiring your own graph, the plugin ships example content: a BP_Examples actor and an L_Demo playable level under the EasyHTTP Content/Examples folder.

Your first GET with Async Quick GET

The quickest way to make an HTTP request in Unreal Engine 5 from Blueprints is the 'Async Quick GET' node. It is a latent async action that takes just a URL and gives you back separate execution pins for the two outcomes you care about, so you do not have to think about delegates or callbacks at all.

1. Open the Blueprint you want to make the request from. An Actor or your Game Instance both work well; for a test you can use the Level Blueprint.

2. Right-click in the Event Graph and add the 'Async Quick GET' node. Wire its input execution pin from wherever you want the request to start, for example Begin Play.

3. Set the URL pin to the endpoint you want to call, for example a JSON API such as https://api.example.com/status. Because this is a quick GET, the request defaults to the GET method, sends and accepts application/json content, and uses a 30 second timeout, so there is nothing else to configure for a basic call.

4. Notice the node exposes two execution output pins, 'On Success' and 'On Failure'. These fire when the request completes, not when it starts, which is what makes this async: your game keeps running while the request is in flight and the matching pin fires once a result is in.

That is the entire request. No C++ class, no delegate binding, no manual JSON setup. The next step is reading what came back.

Reading the response (Break FEasyHTTPResponse)

Both the 'On Success' and 'On Failure' pins carry a Response output of type FEasyHTTPResponse. To read it, drag off that Response pin and add a 'Break FEasyHTTPResponse' node, which splits the struct into its individual fields.

The fields you will reach for most often are bSuccess, a boolean for whether the call completed successfully; StatusCode, the HTTP status returned by the server such as 200 or 404; Content, the response body as a string; and ErrorMessage, which is populated when something went wrong. The struct also carries the raw bytes in RawContent, the response Headers, the RequestStatus, the ElapsedTimeSeconds the call took, and the RequestedURL.

For a typical JSON API you will take the Content string and turn it into usable data. The cleanest route is the engine's built-in 'Json String to Struct' node: define a USTRUCT (or a Blueprint struct) whose field names match the JSON keys, feed in the Content string, and Unreal deserialises it for you. From there you have strongly typed values you can drive your UI or gameplay with, no manual string parsing required.

A practical tip: even on the 'On Success' path it is worth reading StatusCode rather than assuming everything is fine. A request can reach the server and complete the round trip yet still return a 404 or a 500. The 'On Success' pin tells you the HTTP exchange happened; StatusCode tells you what the server actually said.

Handling On Failure properly

It is tempting to wire only the 'On Success' pin and move on, but production code that talks to a network needs the failure path handled. The 'On Failure' pin fires when the request could not complete the round trip at all, for instance because the host was unreachable, DNS failed, or the call timed out.

When 'On Failure' fires, break the FEasyHTTPResponse and read ErrorMessage to find out what happened, log it, and decide how to recover, whether that means showing the player a retry prompt, falling back to cached data, or simply surfacing a clear message instead of a silent hang. Because the request was async, your game was never blocked while waiting, so a graceful failure here is just another branch of normal flow.

There is an important distinction to understand about retries and the difference between the two pins. EasyHTTP's built-in retry logic, which you can enable through the request options on the fuller nodes, fires only on connection failures, never on 4xx or 5xx HTTP responses. The reasoning is sound: a server that answers with 404 or 401 has been reached and has given you a definitive answer, so retrying the same request will only produce the same error. A connection that never landed, by contrast, might succeed on a second attempt. That is why a 404 arrives on 'On Success' with a StatusCode of 404, while a dropped connection arrives on 'On Failure'. Branch your logic accordingly: handle bad status codes on the success path, and handle genuine connection problems on the failure path.

Where to go next: methods, auth and a local test server

Once a quick GET is working, the rest of the API opens up the same way. For posting JSON, reach for 'Async Quick POST JSON', which takes a URL plus a JSON Body string and shares the same On Success and On Failure pattern. When you need full control, the 'Async HTTP Request' and the 'Easy HTTP Request' nodes expose a Method dropdown covering GET, POST, PUT, PATCH and DELETE, and accept an FEasyHTTPRequestOptions struct where you set ContentType, TimeoutSeconds, custom headers and authentication. That Options pin is on Advanced Display, so click the small arrow at the bottom of the node to reveal it.

Authentication is handled by helper builder nodes so you do not assemble headers by hand. There are builders for Basic auth, for Bearer or JWT or OAuth tokens, and for API keys, alongside a custom-header option. Build your options from one of the 'Make Options With...' nodes (or 'Make Default Options' for none), chain 'Add Header To Options' for anything extra, and feed the result into the request node.

Finally, the built-in local test server is the feature that makes Blueprint HTTP development genuinely pleasant. Call 'Start Local Test Server' (it listens on port 8080 by default), point your requests at http://localhost:8080/, use 'Set Server Response' to script what it returns, and inspect what your game actually sent with 'Get Last Server Request'. Remember to call 'Stop All Test Servers' on End Play. The test server is HTTP-only and meant for development, not production, but it lets you build and debug your entire request flow before a real backend exists.

From here you have everything you need to call any REST API from Blueprint. Add EasyHTTP to your project, wire an 'Async Quick GET' to your first endpoint, break the response, and handle both pins. Then layer in POST, headers and auth as your backend grows.

On Success vs On Failure: which pin fires when

EasyHTTP separates HTTP-level results (which complete the round trip) from connection-level failures (which never reach a usable response).

FAQ