Enable canisters to make HTTP(S) requests

I deploy canister locally, got an error:

How to resolve this?
Many thanks

The rust (and I guess Motoko) instructions indicate that you need to deploy with cycles. Maybe you didn’t?

See last section here examples/rust/exchange_rate at master · dfinity/examples · GitHub


Hello, I want to know which subnet supports this?

AFAIK no live subnets currently support it, only the local ones if you enable canister_http. Mainnet support should come soon :tm:


This is correct! We are currently working on the documentation and working on some remaining technical tasks.

You can already work in your SDK environment as @lastmjs has been doing for some time, see some discussions on pitfalls and tips further above. The documentation attempts to capture the issue people have stumbled upon in the forum to help engineers get up to speed quickly.

So the base cost is 400_000_000, what is the cost per byte? And is it just the response bytes or the request and response bytes that add to the cost? Basically I’d like to know how to calculate the cost without trial and error, right now I’m just looking at what the error returns when I perform the call with too few cycles. I’m getting back different requested cycle amounts even though max_response_bytes is set to 200 for each call I’m making.


Here’s the code I’ve been working on BTW. It’s basically an oracle to the Chainlink oracle data on Ethereum or Binance Smart Chain. It will grab ETH/USD, BTC/USD, and ICP/USD prices from multiple Ethereum JSON RPC APIs, compare the results, and use a threshold of the results to come to consensus. It’s been a pleasure to build this and I can’t wait for outgoing HTTP requests to go live: GitHub - demergent-labs/ic_chainlink_data_feeds


What happens if you set max_response_bytes too low?


Awesome, @lastmjs!
Thanks for sharing your code, it will be an inspiration for many others!

According to what @tim1, our network engineer on the project, just told me:
If you set it lower than the actual response size is, you receive an error.


Let me advertise an event by @lastmjs here where he will be looking into using canister HTTP requests for pulling market data from Ethereum. Jordan seems to be one of the first engineers seriously building on top of this soon-upcoming feature!


It already happened, but thanks for the shout-out! Code examples:


Oh no! Missed it!
I interpreted “tomorrow” as today, Aug 12, for a tweet sent on Aug 11 my time. But when you sent it, it was still a day earlier for you, so “tomorrow” referred to a different day. Tricky! :wink:


Maybe once the feature goes live and I can deploy the example to production, I can do another presentation of some kind, with the live results side-by-side.


I don’t think this happens locally…

HI I think I detected a bug in the code that validates the signers of the response, where can I create an issue, the github page doesn’t have that section.
Also are POST requests already allowed in a local replica? I’m using HttpMethod::POST in the call but the server receives a GET request.


Thanks, could you post the bug here in the forum for now so our engineers can have a look at it? POST should be allowed, let me check back on this.

1 Like

@tim1 has tried this out and it worked for him. So we suggest to try to update to the latest SDK version and see whether this fixes the problem with the POST not working.

1 Like


We have 1 small MR with a small fix to merge into our master branch before we can do a soft launch on a first subnet on IC mainnet. I expect the merge to be in within days and a soft launch to happen early next week. Then we will do some more testing on mainnet. The feature integrates tightly with consensus and the whole IC stack, so we need to make sure it does not interfere with the regular functioning of the subnets.

We also need to finish up the documentation which is currently an early draft and still need some effort to get it to where I want it to be. We think that good documentation is extremely important for this feature for the reason that it’s not easy to use and one needs to get accustomed to the potential pitfalls that can cause errors with this feature.

Once the documentation is done (~1 week) and testing with the soft-launched feature has been concluded, we can make a wider rollout of the feature to IC subnets. The NNS will be last as it is the most critical one and does currently not yet need the feature.


Well I may be wrong but it’s on the line 592 (ic/rs/consensus/src/canister_http.rs)

Original code:

if ! invalid_signers.is_empty() {
         return Err(CanisterHttpPayloadValidationError::Permanent(


if invalid_signers.is_empty() {
         return Err(CanisterHttpPayloadValidationError::Permanent(

“invalid_signers” is filtered to only contain the nodes who belong to the http commitee so that code will actually throw an error if some nodes who belong to the commitee are found (vec is not empty), I guess we need some nodes to belong here so it should throw when the vec is empty, it was throwing me an error in the local replica when calling http_request

Hi Dieter, does the team have any plans to enable API keys to be used with HTTP requests? It would be really useful if the IC could query paid for services like Binance or Coinbase, but I worry that without some form of metering or without having the nodes carry their own API keys, it will be difficult to query these services on the IC.