HTTP Requests
Mod Blueprints can make HTTP requests, but only to addresses the player has explicitly approved for your mod.
There are two steps required to make a request:
- You declare the origins your mod wants to access. Use the Conan Exiles Dev Kit window to add these to your
modinfo.json. Declaring an origin grants nothing on its own, it just tells the game to request permission. - The player approves the origin when they start the game. They see the origin and the reason you wrote. Their answer is saved so they are not asked again.
See Requesting Permissions for origin declarations, and the Blueprint Reference for how to make requests from your mod.
A typical request
The Blueprint nodes live under Mod HTTP in the node palette. A simple GET looks like this:
- Call
StartHttpRequest. SetURLtohttps://api.example.com/v1/scoresand leaveVerbon its default ofGET. - Bind the
OnSuccessandOnFailuredelegate pins to custom events. - Store the returned
Request Handleif you want to be able to cancel the request later. - In your
OnSuccessevent, checkIsOKon the result before doing anything with it, then read the body withGetContentAsString.
Point 4 is not optional. OnSuccess means a response arrived, not the server was happy, so a 404 or a 500 fires OnSuccess too. OnFailure is reserved for requests that never completed at all, or that were rejected before being sent. See Failure Types for what each rejection means and how to fix it.
See Blueprint Reference for full details.
Origins
Approval is granted per origin, which is the scheme://host:port part of a URL, omitting the path. Origins are compared exactly, after the host is lowercased and the scheme’s default port is filled in.
Nothing is implied by a related name or port. If the player approves https://api.example.com:
| URL | Allowed |
|---|---|
https://api.example.com/v1/scores | Yes — same origin, path is irrelevant |
https://API.Example.com/v1/scores | Yes — the host is case-insensitive |
https://api.example.com:443/v1/scores | Yes — 443 is the default port for https |
https://cdn.example.com/v1/scores | No — different host |
https://example.com/v1/scores | No — a parent domain is a different host |
https://api.example.com:8443/v1/scores | No — different port |
http://api.example.com/v1/scores | No — different scheme |
Each of those needs its own declaration and its own answer from the player. This is a likely reason a request that looks correct comes back as NotApprovedByPlayer.
Design your mod around a small, stable set of origins. Every extra origin is another prompt the player has to read and answer.
Things to know up front
- Requests are client-side. Each player’s game makes its own requests against their own approved origins. Nothing is replicated, and one player approving an origin does not approve it for anyone else.
- Dedicated servers are configured by hand. A server has no main menu and so never prompts. See Dedicated servers.
- Every request has a deadline. 30 seconds by default, 120 at most. A request that runs over fires
OnFailurewith a failure type ofTimedOut. - Handle lack of permission gracefully. Players remain in control of what their games can and can’t interact with on the Internet, and may deny permission for your mod to make requests. Try to handle a denial gracefully rather than leaving your mod in a broken state.
- Be careful what you send. Anything your mod uploads is data a player did not necessarily intend to share. Ask for the narrowest access that makes your mod work, and say plainly in your reason what you are using it for, since that reason is the only thing the player has to go on.