HTTPS outcalls

In replicated mode, every node of the subnet makes the request and the responses are compared after transformation. If they agree, the result is used and the canister's state can depend on it. This is the mode for reading data that the canister will act on, and it is the mode that requires a transform function.

In non-replicated mode, a single node makes the request and the response is not subject to consensus. The documentation describes this as appropriate for requests whose result does not need to be agreed — sending a notification, posting to an external service, logging — and it is cheaper because only one node performs the work. The trade-off is that the response cannot be trusted as agreed state, and a canister that stores it is storing one node's view.

The documentation also notes that a non-replicated outcall is not free of cost and is not a way to bypass the network's model. It is a different trust assumption, not an exemption from it. The reverse-gas model page covers how outcalls are charged, including the dependence on request size and maximum response size.

The documentation describes the request as carrying a URL, a method, headers and an optional body, and the response as carrying a status code, headers and a body. The canister specifies a maximum response size, and the call fails if the response exceeds it. That is a deliberate constraint: an unbounded response would let an external service consume an arbitrary amount of the network's resources.

The documentation lists the supported methods and notes that the request is made over HTTPS. It also describes the headers the network sets and the ones a canister may not override, which is relevant to any service that expects a particular user agent or authentication header. A canister that needs to authenticate to an external service must hold the credential itself, which means the credential is in the canister's state and visible to anyone who can read it.

That last point is the security consideration the documentation raises. A canister's state is not secret from the nodes that run it, and a canister that holds an API key is trusting the network's operators not to use it. For a service that issues per-application keys this is usually acceptable; for a credential that grants broad access it is not, and the documentation suggests keeping such credentials out of the canister.

The feature is what lets a canister read data the network does not natively track. A price feed, a weather reading, a sports result, an exchange rate — none of these are on the Internet Computer, and all of them are reachable through an outcall. The documentation presents this as the general-purpose escape hatch for external data, in contrast to the chain integrations, which are purpose-built for specific blockchains.

The distinction between the two is worth keeping. A chain integration gives a canister a verified view of another blockchain through a system canister. An HTTPS outcall gives it whatever an external service chooses to return. The first has a defined trust model; the second has the trust model of the service being called, which the network cannot improve.

The documentation also describes the interaction with the on-chain AI services, which are reached the same way. A canister that calls a model endpoint is making an outcall, and the same determinism considerations apply to the response it gets back.