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