Skip to main content

​
Endpoints

An endpoint is a Node API key. You create endpoints in Dashboard → Node API once you have a plan or a trial. Each endpoint has:
  • its own key;
  • its own IP allowlist;
  • its own usage counter — WU and calls for the current period, shown in the dashboard.
The quota and the per-second limits belong to your plan and are shared by all its endpoints: a second endpoint gives you a separate key and counter, not more throughput. How many endpoints you can have depends on the plan — see Plans and billing. The key is shown only once, when the endpoint is created. If you lose it, delete the endpoint and create a new one. In the dashboard you can also edit an endpoint’s IP allowlist, switch it off and on, and delete it:
Changes made in the dashboard — a new endpoint, a new IP allowlist, an endpoint switched off or deleted, a paid renewal — reach the node gateway within about 30 seconds. A key you have just created may get 401 unknown_key during that time.

​
Node API keys and REST API keys

Node API keys are a separate kind of key. An endpoint key works only at node.tronrental.com; the TronRental REST API (api.tronrental.com) refuses it with 403 NODE_API_KEY_ONLY. Your REST API keys, in turn, do not work at the node and get 401 unknown_key there.

​
Passing the key over HTTP

Send the key in one of these places: Header names are not case-sensitive. A key in the path is removed before the request is passed to the node, so the node never sees it.
One request carries one key. The same key sent twice (for example, in the path and in a header) is fine; two different keys are refused with 400 key_conflict, because we cannot tell which of them should pay.
A key in the path is part of the URL, so it ends up wherever URLs are written down: proxy and application logs, monitoring, browser history. Prefer a header when your client lets you set one.

​
Libraries

TronWeb sends the headers you give it:
tronpy sends api_key= only to its default host, so with our address it would send no key at all. Set the header on the provider’s session yourself — or put the key in the path, with the trailing slash: without it tronpy drops the last segment of the address, and the key with it.

​
Passing the key over gRPC

Send the key in the tron-pro-api-key metadata of every call (x-api-key and authorization: Bearer <YOUR_KEY> work too). gRPC has no path to carry a key. See gRPC.

​
IP allowlist

Each endpoint can be limited to a list of IP addresses — IPv4 or IPv6, exact addresses, not ranges. With an empty list the key works from any address. With a list, requests from any other address get 403 ip_not_allowed. An IPv4 address written in IPv6 form (::ffff:203.0.113.7) counts as the IPv4 address itself.

​
Browser apps (CORS)

Node API answers browser requests from any origin, so a dApp can call it directly:
A key in browser code is visible to everyone who opens your app, and anyone who copies it spends your quota. An IP allowlist does not help here — your users’ addresses are not known in advance. Give the browser its own endpoint, keep an eye on its counter, and delete it if it is abused: your server keys keep working.