Chaingateway Polygon API

This is an API for the Polygon blockchain — the proof-of-stake network where POL (formerly MATIC) pays for gas and where USDC and USDT move for pennies. One clarification before anything else: if you are looking for stock and options market data, you want Polygon.io, an unrelated company. This page is about moving tokens on the Polygon chain.

Chaingateway wraps Polygon in REST. Your backend imports wallets and sends ERC-20 tokens over HTTPS, and a webhook reports every incoming deposit within seconds. Authentication is a Bearer token, responses are JSON, and there is no node to run. Registration takes a minute, and the 7-day trial requires no KYC.

Two Polygons: the blockchain and the market-data company

The name collision is worth two more paragraphs, because half the search results for "polygon api" point at the wrong product. Polygon.io is a US company selling market data feeds: stock quotes, options chains, forex candles. Its API answers questions like "what did AAPL trade at yesterday". It has no blockchain, no tokens and no connection to the network this page covers.

Polygon the blockchain, run by Polygon Labs, is an EVM-compatible proof-of-stake network that settles token transactions. Its API surface, whether raw JSON-RPC or a payments layer like Chaingateway, answers questions like "did the customer's USDC arrive" and executes instructions like "pay out 50 USDT". If you need tickers and OHLC candles, close this tab and search for Polygon.io. If you need to move stablecoins with gas fees measured in fractions of a cent, keep reading.

Everything you need to build on Polygon

Webhooks (IPN)

Polygon produces a block about every 2 seconds. When USDC or USDT lands on one of your deposit addresses, Chaingateway POSTs the decoded event to your server as soon as the transfer settles, typically within seconds. Notifications carry an HMAC signature in the X-Signature header once you set a personal secret, and deliveries your endpoint missed sit in a failed-notifications list you can replay from.

Easy transactions

Token transfers on Polygon cost pennies, not dollars, so payout batches that would be uneconomical on Ethereum mainnet are routine here. One POST request sends POL or any ERC-20 token; gas parameters are handled by the API.

Secure address handling

Polygon is EVM-compatible: the same 0x addresses and EIP-55 checksums as Ethereum. The API validates every address before a transaction is built, and the platform is non-custodial, so your keys stay with you.

Decoded queries

Contract events and token transfers come back as decoded JSON instead of raw logs, with amounts already adjusted for token decimals.

Polygon endpoint reference

RPC providers organize their Polygon documentation as long category lists: execution methods here, debug methods there, dozens of entries each. A payments integration needs a shorter map. Chaingateway's Polygon surface spans about thirty endpoints — addresses, balances, blocks, gas price, decoded transactions, NFTs, webhooks — but a payment flow leans on a handful of them:

Category	Method	Endpoint	What it does
Addresses & keys	POST	/api/v2/polygon/addresses	Create a new deposit address
Addresses & keys	POST	/api/v2/polygon/addresses/import	Register an existing private key so the API can send from that address
Transactions	POST	/api/v2/polygon/transactions	Send POL
Transactions	POST	/api/v2/polygon/transactions/erc20	Build, sign and broadcast an ERC-20 transfer
Deposit notifications	POST	/api/v2/polygon/webhooks	Create a webhook for an address
Deposit notifications	GET	/api/v2/polygon/webhooks/notifications	List every webhook notification sent to your server
Account	GET	/api/account	Check your account and plan status

All of them authenticate with the same Bearer token, and adding the header X-Network: testnet points any request at the Amoy testnet instead of mainnet. Request and response schemas are in the API reference.

Stablecoin payments: the reason to pick Polygon

The most common thing built on Chaingateway's Polygon endpoints is stablecoin payment processing, and the economics explain why. Every ERC-20 transfer needs gas. On Ethereum mainnet, gas for a USDT transfer can cost more than a small payment itself; on Polygon, the same transfer costs pennies at most. Charging someone 2 USDC for a digital product is viable here. On L1 it is not.

The numbers back this up. As of mid-2026, fee trackers put a typical USDT transfer on Polygon PoS between a tenth of a cent and two cents, and it rarely exceeds a few cents even when the network is busy. The same transfer on Ethereum mainnet has ranged from well under a dollar in quiet weeks to several dollars during congestion spikes. The gap moves with gas markets, but it has held at two to three orders of magnitude for years, and for a business model built on small payments that gap is the whole business case.

A typical checkout looks like this: your backend assigns the customer a deposit address and shows a QR code, and the customer sends USDC or USDT from any wallet or exchange. About two seconds later the transfer is in a block. The webhook fires, your server verifies the HMAC signature, and the order flips to paid. No card networks, no chargebacks, no waiting for banking hours.

Polygon PoS in numbers

Chain facts drift, so here are the current ones with dates. As of early July 2026:

Blocks arrive every 2 to 2.3 seconds on average, per PolygonScan's block-time data, and transaction finality sits around 5 seconds. For deposits that means the gap between "customer pressed send" and "safe to credit" is measured in single-digit seconds.

The gas token is POL. The migration from MATIC happened on September 4, 2024, at a 1:1 rate, with balances on the PoS chain converted automatically; Polygon reported the migration 99% complete about a year later. Every transaction on Polygon PoS since then has paid gas in POL.

The testnet is Amoy, anchored to Ethereum's Sepolia. It replaced the older Mumbai testnet, which was retired on April 13, 2024, together with the Goerli network it depended on. Tutorials that still say Mumbai are outdated; the flow they describe usually works on Amoy unchanged.

Gas on Polygon: what POL is and who pays it

Every transaction on Polygon consumes gas, and gas is paid in POL, the network's native token. POL replaced MATIC as the gas token in September 2024. Balances on the PoS chain migrated automatically, so older documentation that says MATIC means POL today.

For your integration this means one thing: the address that sends an ERC-20 transfer must hold a small POL balance for gas. The usual pattern is a funded hot wallet for payouts, plus consolidation transfers from deposit addresses that you top up with POL as needed. Since a single transfer burns only a tiny fraction of one POL, a modest float covers a lot of traffic. Gas price settings are chosen by the API, so you never tune gwei values by hand.

Send and receive any token on Polygon, even your own

Every standard ERC-20 contract on Polygon works. USDT, USDC and DAI are supported out of the box, decimals included. If you launched your own token, pass its contract address to the same endpoint and it behaves like any other. NFTs and DeFi tokens follow the same rule. Because the API is identical across chains, code written for Polygon also runs against Ethereum, BSC or Arbitrum once you swap the chain segment in the URL.

Why developers choose Polygon

Throughput is high enough for gaming and other high-frequency workloads, and costs are low enough that use cases priced out of Ethereum L1 become practical. Large consumer brands have shipped loyalty programs and collectibles on Polygon, which has pulled mainstream users onto the network, and institutional projects keep choosing it for settlement. For your team the entry cost is low: the chain is EVM-compatible, so everything you know about Ethereum carries over unchanged.

Quickstart: from key import to confirmed transfer

Three requests cover the whole payment loop. The exact request schemas are in the API reference; for dry runs against the Polygon testnet (Amoy), add the header X-Network: testnet.

Import an existing wallet:

curl -X POST https://app.chaingateway.io/api/v2/polygon/addresses/import \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xYourAddress",
    "privatekey": "0xYourPrivateKey",
    "password": "YourWalletPassword"
  }'

The password protects the imported key on the platform; later sends from that address pass the password instead of the raw key.

Send USDT on Polygon (contract 0xc2132D05D31c914a87C6611C10748AEb04B58e8F):

curl -X POST https://app.chaingateway.io/api/v2/polygon/transactions/erc20 \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contractaddress": "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
    "from": "0xYourSenderAddress",
    "to": "0xRecipientAddress",
    "amount": 5,
    "password": "YourWalletPassword"
  }'

List past webhook notifications, the fastest way to reconcile deposits against your database:

curl https://app.chaingateway.io/api/v2/polygon/webhooks/notifications \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY"

The same three calls translate directly to PHP, Python or Node with any standard HTTP client; there is no Polygon-specific library to install.

From deposit address to credited order

Here is the full receiving flow, the way it runs in production rather than in a demo.

Each customer or order gets its own deposit address, stored in one table: your internal ID, the address, a timestamp. The address in an incoming webhook payload is the lookup key that ties a transfer to an order, and a unique index on that column guarantees no deposit can ever match two orders. If your platform already manages keys, register them once through POST /api/v2/polygon/addresses/import and attach webhooks as described in the webhooks guide.

When the customer pays, the transfer is in a block within about two seconds and the notification hits your endpoint moments later. Your handler verifies the HMAC signature first, looks up the order by address, and then checks one more thing before crediting: whether it has seen this transaction hash before. Store every processed hash with a unique constraint and let the database refuse duplicates. A delivery your server missed is not gone: it appears under GET /api/v2/polygon/webhooks/notifications/failed, and POST /api/v2/polygon/webhooks/notifications/{id}/retry sends it again, so a timeout on your side never loses a deposit; idempotent processing is what keeps a replayed notification from crediting one twice.

How long to wait before releasing goods is a business decision, not a technical one. Finality on Polygon arrives around 5 seconds after inclusion, so even a cautious policy costs little: credit a 3 USDC purchase on the first notification, hold a four-figure deposit until your reconciliation check against GET /api/v2/polygon/webhooks/notifications confirms it. That endpoint doubles as your audit trail; a nightly diff against your own ledger catches anything a two-hour outage might have obscured.

Deposit addresses fill up over time, so schedule a sweep: a job that consolidates balances into your treasury wallet with the same POST /api/v2/polygon/transactions/erc20 call, from set to the deposit address. Each swept address needs a trace of POL for gas, which at Polygon prices is small enough to pre-fund in bulk.

Payouts without double-sends

Withdrawals are the flow where mistakes cost money directly, and two habits remove most of the risk.

Validate before you queue. A destination address must decode as a 20-byte 0x value, and when it contains mixed-case letters, the EIP-55 checksum must match. Reject failures at the form, where the user can fix a typo; the API validates again before broadcasting, but the earlier the catch, the cheaper it is.

Write first, send second. Create one database row per payout with a state machine (queued, sent, confirmed), let a worker make exactly one POST /api/v2/polygon/transactions/erc20 call per row, and store the returned transaction hash immediately. Give the user that hash as a PolygonScan link, and they can track their own withdrawal instead of writing to support. If the API call times out, do not fire again on reflex: check the notification list and your own records to confirm nothing went out, then retry deliberately. The hot wallet needs a POL float for gas; on Polygon a small balance covers thousands of transfers, so a monthly top-up is enough.

Testing on Amoy before mainnet

Amoy is Polygon's Sepolia-anchored testnet, live since early 2024 as the replacement for Mumbai, and every endpoint on this page runs against it when you add one header:

X-Network: testnet

No separate account, no second key, no other change. Test POL comes from the public Amoy faucets, and the addresses and mechanics match mainnet exactly.

Spend the test run on failure paths rather than the happy path. Kill your webhook endpoint, send a deposit, bring the endpoint back, then read the failed-notifications list and replay the delivery through the retry endpoint. Replay a notification you already processed and confirm your idempotency check rejects it. Submit the same payout twice and verify only one leaves. Each rehearsal takes minutes on Amoy and prevents a real incident later; when all three hold, drop the header and the identical code is in production.

Webhook security in practice

Your webhook endpoint feeds your ledger, so harden it like any other money-adjacent input.

Signature first. Set a personal secret in your profile settings, and every notification carries an X-Signature header: a base64-encoded HMAC-SHA256 of the payload's txid, keyed with that secret. Recompute it and compare in constant time before touching the rest of the payload. Anything that fails gets a 4xx response and no processing. Verification examples in Python, Java, PHP and JavaScript are in the webhooks guide.

Chaingateway's IP whitelist guards the other direction: in the account panel you can limit API access to a list of your own server IPs, so a leaked API key is useless from anywhere else. It protects your key, not your webhook receiver — for the receiver, the signature is the authenticity check. Against replayed notifications, which carry valid signatures by definition, your transaction-hash constraint is the defense; a duplicate gets acknowledged and dropped. Serve the endpoint over HTTPS only, and keep secrets out of the URL, because URLs leak into logs on infrastructure you do not operate.

When requests fail

Errors come back as standard HTTP status codes with JSON bodies, so your usual patterns apply unchanged.

A 401 is an authentication problem: the Bearer token is missing, revoked or mistyped. Other 4xx responses are validation failures, a bad checksum or an unknown field, and the body names the offender; retrying the identical request cannot succeed. A 429 means the plan's rate limit is reached; back off with increasing delays, and look at the pricing page if you hit it in normal operation rather than in bursts.

For 5xx responses, retry reads freely. Retry sends only after you have confirmed, via the notification list and your own payout rows, that the first attempt was not broadcast. Keep the full response body in your logs next to the request that caused it; that pairing shortens every debugging session and support exchange. Per-endpoint status codes and error schemas are in the API reference.

Built for every use case

The core pattern is payment acceptance: a deposit address per order, a webhook per incoming transfer, settlement in seconds. Merchants use it for checkout, and platforms use it for user balances, watching deposits and processing withdrawals across thousands of addresses through the same endpoints.

The low gas costs open patterns that are dead on arrival elsewhere: micro-payouts to content creators, airdrops and vesting schedules executed as plain ERC-20 transfers, recurring subscription billing in stablecoins, and cross-border payments where the fee is cents instead of a percentage.

Integration in four steps

1. Get your API key. Register and the key is in your dashboard right away. The 7-day trial needs no KYC.
2. Make your first request. The quickstart takes you from sign-up to a first transaction.
3. Set up webhooks so deposits push to your server. Signatures and the notification history are covered in the webhooks guide.
4. Go live. Remove the X-Network: testnet header and the identical code runs on mainnet.

Frequently asked questions

Is this the Polygon API for stock market data?

No. Polygon.io sells market data for stocks and options and has no connection to the Polygon blockchain. Chaingateway's API moves tokens on the Polygon proof-of-stake network. If you came for tickers and OHLC candles, this is the wrong Polygon.

What is the difference between MATIC and POL?

POL is the renamed and upgraded network token. The switch happened in September 2024, at a 1:1 rate, and balances on the Polygon PoS chain were converted automatically. Gas is paid in POL today, and most exchanges have relabeled MATIC accordingly. If your code or docs still say MATIC, the mechanics are unchanged; only the ticker moved.

How is gas paid when I send USDC or USDT?

Gas comes out of the POL balance of the sending address. Keep a small POL float on your hot wallet; because each transfer burns only a tiny fraction of one POL, topping up is an occasional task rather than an operational burden. The API sets gas parameters automatically.

How fast are Polygon deposits confirmed?

Blocks arrive every 2 to 2.3 seconds, and finality follows about 5 seconds after inclusion, as of mid-2026. The webhook for an incoming transfer fires once the transfer settles, so your server typically knows about a deposit within a few seconds of the customer sending it.

What is the Amoy testnet?

Amoy is Polygon's current PoS testnet, anchored to Ethereum's Sepolia. It replaced Mumbai, which was retired on April 13, 2024. With Chaingateway you reach Amoy by adding the X-Network: testnet header to any request; there is no separate account or key.

What happens if my webhook endpoint goes down?

Nothing is lost. Deliveries that failed are kept under GET /api/v2/polygon/webhooks/notifications/failed, and POST /api/v2/polygon/webhooks/notifications/{id}/retry re-sends any of them once your endpoint is back. GET /api/v2/polygon/webhooks/notifications lists everything that was sent, and a diff against your database restores any missed deposits. Idempotent handling by transaction hash keeps replays from crediting twice.

How are private keys handled?

The platform is non-custodial: you control the keys to your funds. For automated flows, existing keys can be registered through POST /api/v2/polygon/addresses/import. The details are documented in the API reference.

Can I use the same integration for other chains?

Yes. The endpoint structure is consistent across Bitcoin, Ethereum, BSC, TRON, Solana and Arbitrum; on the EVM chains, usually only the chain segment in the URL changes. Build your payment flow once on Polygon and reuse it wherever your users are.

Which tokens on Polygon are supported?

Any standard ERC-20 contract, including USDT, USDC, DAI and tokens you deployed yourself. You pass the contract address in the request, and the API applies the token's decimals automatically. There is no allowlist and nothing to request from support.

What about rate limits and pricing?

Limits depend on your plan; the current numbers are on the pricing page. Every account starts with the free 7-day trial, which is enough to build and test the full integration.

Ready to build on the Polygon blockchain?

Create your account, import a wallet and send your first Amoy testnet transfer today. The full endpoint reference is at /docs/, and the developer portal has tutorials for the most common payment flows.