Troubleshooting

Deposits

My deposit hasn’t arrived

Work down this list:

1. Give the network a moment. Crediting happens after the deposit confirms on-chain, not when you hit send.
2. Check the chain. The deposit address is TRON (TRC-20). USDT sent from Ethereum, BNB Chain or an exchange’s internal network never reaches it — and cannot be recovered.
3. Check the minimum. Deposits below the minimum shown in the Top up dialog may not credit.
4. Check the address. It must be the address from your own Top up dialog, not one from a guide or a screenshot.

Once it credits you get a deposit.credited notification and it appears in Transactions.

Can I deposit TRX directly?

Yes. Balances are held in TRX, so a TRX deposit skips conversion entirely. USDT-TRC20 is converted at the current rate on arrival.

Orders

My order says Created, not Filled

That’s normal for a moment. An order is Created when we take the payment and start delivery, and becomes Filled when delivery is confirmed — usually within seconds.

Don’t poll it in a loop. It settles on its own, and you’ll get a notification (or an order.filled webhook).

My order failed — where’s my money?

Back on your balance. A failed order is refunded automatically; you’ll see the refund in Transactions and get an order.failed notification. If the balance doesn’t reflect it, tell us the order id.

Why did it cost more than the preview said?

Almost always address activation: an address that has never transacted on TRON must be activated once, which costs an extra 2 TRX. The preview only knows to include it if you filled the address in before reading the number. Preview again with the address in place and it will match.

The energy arrived but disappeared later

Rented energy is temporary — it returns when the rental period you chose expires. If you need it to stick around, rent for longer, or use an automation so it’s replenished.

Automations

My rule paused on its own

Your balance couldn’t cover the next delivery, so we paused it rather than fail it. Top up, then resume.

Turn on auto-resume and this heals itself: a system-paused rule restarts once your balance can cover a delivery again. A rule you paused is never auto-resumed — that’s deliberate.

I topped up but it didn’t resume

Three things to check:

1. Is auto-resume on? It’s opt-in, per rule.
2. Is there enough for a full delivery? Resuming into a balance that can’t cover one firing would just pause it again, so it doesn’t.
3. Who paused it? If you paused it by hand, only you can restart it.

My rule is active but nothing’s being delivered

An active rule that goes quiet longer than its schedule implies is something we detect and flag internally. If an address isn’t getting energy and the rule looks healthy, contact us with the rule and address — don’t just delete and recreate it, as that loses the history we’d use to diagnose it.

Can I automate bandwidth?

No. Automations are energy only — bandwidth is available as a one-off purchase. Order it manually from Orders.

API and agents

403 api_key.insufficient_scope

The key isn’t allowed to do that. Scopes nest: full ⊇ purchase ⊇ read. Reading needs read, spending (orders, automations) needs purchase, managing webhooks needs full. Issue a key with the right scope — see Authentication.

403 api_key.spend_limit_exceeded

The key hit its daily spend limit. The limit is per key, per UTC calendar day, and it counts both orders the key placed and deliveries from automations that key created. Raise the limit or wait for the day to roll over.

This is working as designed — it’s the guardrail that makes handing a key to an agent safe.

402 wallet.insufficient_balance

Not enough TRX. This also fires when creating a renewal or enabling smart mode, because both require enough balance for at least one delivery up front.

I lost my API key

Keys are shown once and stored hashed — we can’t recover it. Revoke it and issue a new one.

Webhooks

I’m not receiving deliveries

Check the endpoint’s delivery log in the dashboard first — it shows each attempt and the response we got. Then:

1. Is the endpoint enabled? Disabled endpoints are skipped silently.
2. Are you returning 2xx? Anything else counts as a failure and gets retried (about 30s → 6h, up to 6 attempts), after which the delivery is marked failed.
3. Are you subscribed to that event? An endpoint only receives the event types you selected for it.
4. Send a test ping to check the path end-to-end.

Adding the endpoint failed instead?

We only accept public HTTPS URLs. http://, localhost and private or internal IP addresses are rejected when you add the endpoint — so if you’re developing locally, put a tunnel in front of your receiver.

Signature verification fails

Nearly always one of these:

1. You verified a parsed body. Sign the raw bytes, before any JSON parsing or re-serialisation — a re-encoded body has different whitespace and the HMAC won’t match.
2. You left out the timestamp. The signed string is {timestamp}.{rawBody}, not the body alone.
3. You rotated the secret and the receiver still has the old one.

The format and a worked example are in the Webhooks reference.

I got the same event twice

By design — retries mean at-least-once delivery. De-duplicate on the X-TronGas-Delivery header.