Documentation
Connect your Polygon endpoint fast
From account to first authenticated request in a few minutes using standard JSON-RPC tooling.
Quickstart in 3 steps
1. Create account
Sign up with your email and get into the console without a separate onboarding process.
2. Generate API key
Create the key in the console and copy it immediately. The raw value may only be shown once.
3. Send first request
Use the same JSON-RPC tools you already use for Polygon. No custom client library is required.
Time to first request
Usually under 2 minutes once your key is created
This page is intentionally copy-paste friendly. If your request is failing, it is usually one of a small set of mistakes rather than a hidden integration layer.
Authentication
Use your API key in the x-api-key header
BlazingNode uses a straightforward header-based authentication flow. Send your API key directly in the x-api-key header with requests to your Polygon RPC endpoint.
POST https://rpc.blazingnode.com
Content-Type: application/json
x-api-key: YOUR_API_KEY
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_blockNumber",
"params": []
}Common mistakes
- Missing x-api-key header
- Invalid API key
- Wrong content-type
- Expecting a custom API instead of standard JSON-RPC
Endpoints
Common Polygon JSON-RPC methods
BlazingNode is meant to drop into standard tooling. Here are a few request patterns developers usually hit first.
eth_blockNumber — Returns the number of the most recent block.
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_blockNumber",
"params": []
}Result format
Returns a hex quantity string. Convert the hex value to decimal if you want a human-readable block number.
{
"jsonrpc": "2.0",
"id": 1,
"result": "0x5094dc0"
}eth_call — Executes a message call without creating a transaction on-chain.
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_call",
"params": [
{
"from": "0x...",
"to": "0x...",
"data": "0x..."
},
"latest"
]
}Result format
Returns ABI-encoded hex data. The exact meaning depends on the contract function you called.
{
"jsonrpc": "2.0",
"id": 1,
"result": "0x0000000000000000000000000000000000000000000000000000000005f5e100"
}eth_getBalance — Returns the balance of the account for a given address.
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBalance",
"params": ["0x...", "latest"]
}Result format
Returns a hex quantity string in wei. Convert it from hex first, then from wei to POL if needed.
{
"jsonrpc": "2.0",
"id": 1,
"result": "0xde0b6b3a7640000"
}Examples
First request, no custom tooling
Copy one of these, swap in your key, and you are live on a normal JSON-RPC request flow.
const url = "https://rpc.blazingnode.com";
const payload = {
jsonrpc: "2.0",
method: "eth_blockNumber",
params: [],
id: 1,
};
const response = await fetch(url, {
method: "POST",
headers: {
"Content-Type": "application/json",
"x-api-key": "YOUR_API_KEY",
},
body: JSON.stringify(payload),
});
if (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}
const data = await response.json();
console.log(data);Compare before you switch
Want to compare your current endpoint first? Start with the provider methodology and the common failure guides.
FAQ
Practical questions
How quickly can I get to a first request?
Usually under 2 minutes once your key is created. The flow is: create account, create key, send a standard JSON-RPC request.
Do I need to learn a custom API?
No. BlazingNode is standard Ethereum-style JSON-RPC. If you already know Polygon tooling, the request format should feel familiar.
Where does the API key go?
Send it in the x-api-key header on every request. If that header is missing, the request will fail even if the payload looks correct.
Do I need to reason about compute units?
No. Pricing is described in practical request limits and workload fit, not opaque usage formulas.
What should I do before switching production traffic?
Compare the same workflow against the provider methodology and fix guides first. If public RPC instability is already concrete, request trial access only after the problem is clear enough to validate against dedicated access.
What if my client reports a certificate validation problem?
Standard clients expect a trusted TLS certificate. If you see a self-signed or certificate validation error, pause before sending production traffic and verify the live edge certificate rather than disabling verification in a real workflow.