Data API keys, quotas and read-only access

WalletFollow Data API keys authenticate supported read-only requests and consume a plan’s weighted budget. They do not authorize venue orders, transfers or withdrawals. Keep the key in a secure runtime, read the current catalog for limits, and use usage information and retry headers to control request volume.

A service key is not a wallet key

A Data API key identifies access to a data account. A wallet private key controls a signing identity, and an engine agent key carries venue execution authority. Never substitute one for another. Public-wallet research only needs the account address plus the data-service authentication required by the chosen integration.

Create and revoke service keys through the account console. Give each integration a clear purpose so you can remove access when it is no longer needed. Avoid placing keys in URLs, browser-visible client bundles, screenshots or saved AI transcripts.

Count request weight rather than just requests

The API catalog lists endpoint weights and variants. The wallet summary currently uses a lower weight than the variant requesting trade analysis. Ten detailed requests can therefore consume more budget than ten summaries. The correct workload estimate multiplies each request count by its catalog weight.

Plan limits can apply over short bursts, minutes and monthly usage. A client that stays below the monthly allowance can still exceed a burst limit. Use a controlled queue and avoid launching hundreds of wallet lookups simultaneously.

Handle errors according to their meaning

On 429, read the error code and Retry-After before retrying. A minute limit and an exhausted monthly quota have different recovery conditions. On 401, review whether the key is missing, expired or revoked. On an unavailable-data response, preserve that result rather than fabricating a successful wallet report.

Use GET /v1/usage to monitor the account budget and GET /v1/catalog for current endpoint details. A free or paid plan label alone does not tell a client exactly how much a specific workload will consume.

Protect reports and logs

Log request identifiers, endpoint names and error codes without the Authorization header. Redact credentials from exception messages and copied commands. An assistant’s final research output should include public addresses and relevant data observations, not the key that retrieved them. If a key appears in a public place, revoke it and update the integration rather than assuming deletion removes every copy.

  • Store keys outside source code and prompt text.
  • Deduplicate requests and choose the lightest useful variant.
  • Respect retry instructions.
  • Review access and revoke unused integrations.

Sources and further reading