HTTP Requests

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:

  1. 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.
  2. 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:

  1. Call StartHttpRequest. Set URL to https://api.example.com/v1/scores and leave Verb on its default of GET.
  2. Bind the OnSuccess and OnFailure delegate pins to custom events.
  3. Store the returned Request Handle if you want to be able to cancel the request later.
  4. In your OnSuccess event, check IsOK on the result before doing anything with it, then read the body with GetContentAsString.

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:

URLAllowed
https://api.example.com/v1/scoresYes — same origin, path is irrelevant
https://API.Example.com/v1/scoresYes — the host is case-insensitive
https://api.example.com:443/v1/scoresYes — 443 is the default port for https
https://cdn.example.com/v1/scoresNo — different host
https://example.com/v1/scoresNo — a parent domain is a different host
https://api.example.com:8443/v1/scoresNo — different port
http://api.example.com/v1/scoresNo — 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 OnFailure with a failure type of TimedOut.
  • 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.
Last updated on