> For the complete documentation index, see [llms.txt](https://docs.catfee.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catfee.io/en/getting-started/seamless-energy/quick-start.md). # Quick Start This guide is for developers integrating CatFee Seamless Energy for the first time. The goal is to complete node application, authentication setup, broadcast entry replacement, and the first broadcast verification with the fewest steps. ## Who should read this page * Suitable for: backend developers, wallet service providers, DApp developers, and transaction relay services. * Also suitable for: product or technical owners who need to determine the boundary between wallet configuration and server-side integration. * Not the best fit for: ordinary wallet users who only want to manually configure TronLink. If you only want to manually configure a wallet, read [Wallet Settings](/en/getting-started/seamless-energy/wallet-settings.md). ## 3-minute runnable path If you want to verify that the feature works first, follow this shortest path: 1. Apply for a node in "User Center -> Seamless Energy". 2. Locate the signed transaction broadcast entry point in your system. 3. Developers should prefer API KEY authentication and store the AccessKey in a server-side environment variable. 4. Only replace the broadcast domain with the Seamless Energy node domain. Keep the original broadcast path and request body unchanged. 5. Send a small TRC20 transfer or approval transaction to verify the result. After this works, return to review the insufficient balance policy, security notes, and full integration details. ## Prerequisites * You have a CatFee member account. * You have a wallet or backend service that can initiate TRON transactions. * You understand your integration mode: backend direct call, in-app integration, manual wallet configuration, or self-built middleware. * If you use API KEY mode, you have a secure place to store the AccessKey. > Seamless Energy only handles the broadcast flow of signed transactions. If you are only querying on-chain data, or if you do not control transaction broadcasting, read [Application Integration](/en/getting-started/seamless-energy/application-integration.md) first to confirm the boundary. ## Steps ### 1. Apply for a Seamless Energy node Log in to the CatFee website and apply for a node in "User Center -> Seamless Energy". After the application succeeds, the system generates a dedicated access domain: ``` https://{NodeSlug}.catfee.vip ``` Example: ``` https://bright-blue-river.catfee.vip ``` ### 2. Locate the broadcast entry point Seamless Energy only enhances the broadcast stage of signed transactions. Before integration, confirm which code path ultimately calls the TRON broadcast API. Common keywords include: ``` broadcasttransaction broadcasthex BroadcastTransaction sendRawTransaction tronWeb.trx.sendRawTransaction ``` If you want AI to help locate the code, refer to the prompts in [AI-Assisted Integration](/en/getting-started/seamless-energy/ai-assisted-integration.md). Code and logs provided to AI should be sanitized first. Do not include private keys, mnemonic phrases, keystore files, real AccessKeys, or production node domains. ### 3. Choose an authentication method Choose an authentication method based on your scenario: * Developers or wallet service providers: prefer API KEY. Requests must pass `CF-NODE-KEY: {AccessKey}` in the HTTP header or gRPC metadata. * Ordinary wallet users or clients that do not support custom headers: prefer bound address. The owner address of the first transaction in the request must be bound to the node. * Temporary testing: no authentication can be used, but it is not recommended for long-term public use. If you use API KEY, subsequent requests need to pass: ```http CF-NODE-KEY: {AccessKey} ``` ### 4. Replace the broadcast node Replace the node domain used to **broadcast signed transactions** with the Seamless Energy node domain. Keep the request path and request body in the original TRON format. Common HTTP broadcast paths: ```http POST https://{NodeSlug}.catfee.vip/wallet/broadcasthex POST https://{NodeSlug}.catfee.vip/wallet/broadcasttransaction ``` Common gRPC broadcast configuration: ``` Server: {NodeSlug}.catfee.vip Port: 443 SSL/TLS: enabled Broadcast path: /protocol.Wallet/BroadcastTransaction ``` ### 5. Configure the insufficient balance policy In the CatFee User Center, choose how to handle insufficient member balance: * Continue broadcast: skip ENERGY purchase and continue forwarding the original transaction. * Stop broadcast: return `402 PAYMENT_REQUIRED` and do not continue broadcasting. ### 6. Complete the first verification Use a small TRC20 transfer, approval, or low-risk contract call to complete end-to-end verification. Prioritize verifying the following: * The node domain is accessible. * The authentication method is configured correctly. * Contract transactions trigger ENERGY estimation and resource preparation. * The broadcast response format is compatible with the original TRON node. Do not use a regular TRX transfer as the first test, because non-contract transactions do not trigger resource preparation. ## Verification results After the first verification, you should usually be able to confirm: * The wallet or backend still signs locally, and the signing flow does not need to change. * CatFee prepares resources before broadcasting supported contract transactions. * Non-contract transactions are forwarded directly and do not purchase additional ENERGY. * The original broadcast API and response format remain compatible, with one additional resource preparation step before broadcast. ## Common issues * If the node does not exist, the domain is usually incorrect or the node has been deleted. * If the node is disabled, re-enable it in the User Center first. * If the member balance is insufficient, recharge or check whether continuing broadcast is allowed. * If requests are rate-limited, reduce the request rate. ## Next steps * Developer integration details: [Application Integration](/en/getting-started/seamless-energy/application-integration.md). * AI-assisted refactoring: [AI-Assisted Integration](/en/getting-started/seamless-energy/ai-assisted-integration.md). * Manual wallet configuration: [Wallet Settings](/en/getting-started/seamless-energy/wallet-settings.md). * Other client integrations: [Other Wallets and Apps](/en/getting-started/seamless-energy/wallet-settings/other-wallets-and-apps.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.catfee.io/en/getting-started/seamless-energy/quick-start.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.