Internet Computer Launches Flexible HTTPS Outcalls for Developers

Internet Computer developers can now use flexible HTTPS outcalls through a new management-canister method called flexible_http_request. The feature lets applications choose how many subnet nodes make an HTTPS request and how many responses are required, giving developers more control over trust, cost, latency and fault tolerance.

What flexible outcalls add

Traditional replicated HTTPS outcalls can require subnet nodes to agree on a response before a canister uses it. DFINITY’s new feature returns individual node responses instead, allowing an application to decide how much agreement or redundancy it needs for a particular request.

The approach is useful when web data is not perfectly identical across requests or when an application has its own way to validate responses. It also gives developers a way to make explicit trade-offs rather than applying one response policy to every external call.

Reported detail	Flexible HTTPS outcalls
Feature	flexible_http_request
Control plane	Internet Computer management canister
Configurable values	min_responses, max_responses and total_requests
Response model	Individual node responses rather than mandatory byte-for-byte agreement
Failure handling	Typed failure modes
Developer support	Rust usage, interface specification and GitHub example

How the request controls work

The request can specify a total number of node requests and thresholds for the responses returned to the canister. A higher number of requests may improve redundancy or help identify inconsistent data, while lower thresholds may reduce latency and cost.

The feature therefore moves an important design decision to the application. A developer can choose how much evidence is enough for a price feed, availability check, data lookup or other external interaction. Typed failures can also help a canister distinguish an unsuccessful request from a response set that does not meet its configured requirements.

Flexible responses do not turn an external website into a trusted oracle. They give the canister more information and control, but the application still needs to evaluate authenticity, freshness, manipulation risk and source availability.

What developers should assess

Before using flexible outcalls in production, teams should test the response policy against inconsistent data, slow nodes, unavailable endpoints and malicious or compromised sources. They should document why a particular request count and response threshold is appropriate for the application’s risk model.

Developers should also measure cycles consumption, timeout behavior, retry logic and the impact of multiple external requests on user experience. Applications that use financial or security-sensitive data may need independent validation, signed responses or multiple sources rather than relying only on a threshold of returned answers.

Read the official DFINITY developer announcement. Follow more blockchain developer coverage at VORTFLUX.