Tenant Isolation in Wallet Data APIs
Enforce ownership on every wallet-data resource request, and prevent guessed IDs or shared caches from exposing another customer’s imports and reports.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
Knowing a resource ID is not authorisation. Multi-tenant APIs must bind the authenticated caller to the requested project, wallet connection, import or report at the server boundary.
Check the resource relationship
Resolve the caller’s allowed tenant and project scope before returning resource data. Do not trust a tenant ID supplied in the request body as proof of ownership. Background jobs and exports need the same checks as interactive routes. Cache namespaces must preserve access scope when responses contain customer-specific information.
Worked example: a guessed import ID
Customer A requests an import ID belonging to B. The route finds the import successfully, but must still reject access because its owner scope does not match A. Returning the record merely because the ID exists is an object-level authorisation failure, even if the underlying wallet address is publicly visible on-chain.
Test every consumer path
Include list, detail, download, retry and worker endpoints. Test revoked project access and a resource moved or reassigned under supported rules. Keep public chain evidence distinct from private customer context, labels and usage. A public transaction does not make an application’s ownership links or report contents public.
A practical acceptance test
Create resources for tenants A and B, then exercise list, detail, export and retry routes using A’s session and B’s IDs. Every private path should enforce ownership even though the underlying wallet is public. Add a shared-cache fixture and verify that enriched labels from B never appear in A’s response or diagnostics.
Questions about the topic
Frequently asked questions
Does a public wallet address make customer reports public?
No. Application context can remain private.
Is authentication enough to access any valid resource ID?
No. Resource-level authorisation is also required.
Standards & technical documentation
