TEnergy vs TronZap: price, speed and API compared
Official SDKs on npm, PyPI and Packagist, a resource-bundle product, and a three-level referral programme paying up to 5%.
- Off-peak until 11:00 UTC UTC
- 1h energy 20 SUN
- 65k · 1h 1.30 TRX
If you already run against TronZap, the switch is a constructor change: Swap the import and the credentials. Class names, method names, argument order and error classes are preserved. The table below is every difference we can state as a fact, and the section after it is what TronZap does that we do not.
Side by side
| Dimension | TronZap | TEnergy |
|---|---|---|
| Tiers | 1 hour and 24 hours | 5m, 1h and 1d today |
| Auth | Bearer token plus X-Signature = sha256(body + secret) | X-API-KEY with base64 HMAC-SHA256 over timestamp, method, path, query and body |
| Order endpoint | POST /v1/transaction/new with a service field | POST /v1/orders, with resource and tier as first-class fields |
| Resource bundle | A bundle product (energy plus bandwidth in one call) | No bundle product — the compat shim places two orders and reports the worse status |
| SDKs | npm, PyPI, Packagist | TypeScript and Python, plus four compatibility shims |
| Subscriptions | Offered | Phase 2 |
| Referral | Three levels, up to 5% | A referral programme with credit on the first settled order |
| Delivery notification | Poll transaction/check | Signed webhooks, or the same polling as a fallback |
| Testnet | None | Nile, on a separate host with separate keys |
What TronZap does that we do not
- Official SDKs in three package ecosystems, and an address-activation and resource-bundle product line.
- AML screening and a three-level referral programme, neither of which is a phase-1 product for us.
Migration in 5 minutes
Install @tenergy/tronzap-compat, change the constructor, and your call
sites keep working. The block below is the migration guide itself — it is generated from the
compatibility documentation, so it cannot drift from the shim that implements it.
1. npm remove tronzap-sdk && npm install @tenergy/tronzap-compat. 2. Swap the import and the credentials — that is the whole change:
- import { TronZapClient } from 'tronzap-sdk';
+ import { TronZapClient } from '@tenergy/tronzap-compat';
const client = new TronZapClient({
- apiToken: process.env.TRONZAP_TOKEN, apiSecret: process.env.TRONZAP_SECRET });
+ apiToken: process.env.TENERGY_KEY, apiSecret: process.env.TENERGY_SECRET,
+ baseUrl: 'https://api.tenergy.me' });The class name, method names, argument order, returned result shapes and error classes are preserved: createEnergyTransaction(address, 65000, 1, 'my-external-id-123', true) then checkTransaction(tx.id) still yields status.status === 'success' with status.hash and status.amount as "3.000000"; estimateEnergy, calculate, getServices, getBalance, getAddressInfo behave as before; catch (e) { if (e instanceof ApiError && e.code === ErrorCode.INSUFFICIENT_FUNDS) …; if (e instanceof RateLimitError) … } is unchanged.
3. If you use `createResourceBundleTransaction`, read this. We have no bundle product: the facade places two orders and reports the energy order's id, with checkTransaction returning the worse of the two statuses — so success still means *both* halves landed. What changes: the halves can fail independently, and a failed bundle may have delivered the energy. Use client.getBundleParts(id) (facade-only) if that matters, or move to two explicit native orders. 4. If you use subscriptions or `direct-recharge-info`, test them specifically — those mappings are experimental: their official Node SDK exposes no subscription methods, so we had no verified request or response shape to build against. 5. Rehearse on Nile: baseUrl: 'https://api-nile.tenergy.me' with testnet keys; TronZap has no testnet, so this is new.
Behaves differently: 1 resource_bundle is two orders under the hood (step 3). 2 subscriptions and direct-recharge are experimental (step 4). 3 address-info returns no TRC-20 token balances — TRON resources only. 4 durations are still 1 and 24; shorter tiers (5m, 15m) exist but are not reachable through this facade — use the native client. 5 AML calls throw NotSupportedByFacade rather than reaching the network. 6 you can stop polling: transaction/check still works, but the native API has signed webhooks — order.confirmed arrives the moment the delegation is verified on chain, which is the main thing worth leaving the facade for.