> 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/wallet-settings/other-wallets-and-apps.md).

# Other Wallets and Apps

Besides TronLink, any wallet, DApp, backend service, or middleware that can control the TRON transaction broadcast target can integrate CatFee Seamless Energy.

## Applicable scenarios

* Desktop or mobile wallets that support custom TRON nodes.
* Self-built backend services responsible for centrally broadcasting signed transactions.
* Wallet aggregators, custody panels, or multi-tenant business systems.
* Server-side applications that connect directly to TRON nodes through gRPC.

## Which authentication method to choose

### Bound address

Suitable when:

* The wallet does not support custom Headers.
* The number of addresses is limited.
* You want to keep configuration complexity low.

Validation rule:

* The owner address of the first transaction in the request must be bound to the node.

### API KEY

Suitable when:

* Transactions are broadcast centrally by a backend.
* There are many addresses and binding them one by one is inconvenient.
* The client supports HTTP Header or gRPC metadata.

API KEY is passed through this field:

```http
CF-NODE-KEY: {AccessKey}
```

Validation rule:

* The passed value must match the 41-character random `AccessKey` stored for the node.

### No authentication

Only suitable for temporary testing or scenarios where you explicitly accept the risk of open access. It is not recommended for long-term use.

## HTTP application integration

If the application currently calls a TRON node through HTTP, only replace the broadcast domain and keep the original path:

```http
POST https://{NodeSlug}.catfee.vip/wallet/broadcasthex
POST https://{NodeSlug}.catfee.vip/wallet/broadcasttransaction
```

The request body remains in the original TRON format.

## gRPC application integration

If the application currently calls a TRON node through gRPC, usually you only need to replace the target server and keep the broadcast method unchanged:

```
Server: {NodeSlug}.catfee.vip
Port: 443
SSL/TLS: enabled
Broadcast path: /protocol.Wallet/BroadcastTransaction
```

If API KEY is used, pass `CF-NODE-KEY` through gRPC metadata.

## Recommended integration methods

* Pure wallet-side integration: prefer bound address.
* Wallet plus self-owned backend: prefer backend API KEY.
* Enterprise multi-address business: use centralized backend broadcasting and manage the AccessKey centrally.

## Common notes

* Only send signed transactions. Do not upload private keys, mnemonic phrases, or keystore files to CatFee.
* The node domain is used for routing and should not be distributed publicly as the only credential.
* If the UI layer cannot customize authentication headers, prefer bound address mode.
* Before changing nodes, verify the full flow with a small contract transaction.

## Next steps

* Developer details: [Application Integration](/en/getting-started/seamless-energy/application-integration.md).
* Risk boundaries: [Security](/en/getting-started/seamless-energy/security.md).
* Common errors: [FAQ](/en/getting-started/seamless-energy/faq.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/wallet-settings/other-wallets-and-apps.md?ask=<question>&goal=<endgoal>
```

`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.