A multi-tenant integration needs evidence that one workspace cannot access another's private listener state. Testing only the first workspace's successful request does not check that boundary.
Create two controlled workspaces and two listener accounts through supported test setup. Give them clearly different fixture data so an accidental crossover is easy to spot.
Try the wrong combinations
Use workspace A's permitted caller with workspace B's listener identifier, following the API's documented paths. Repeat with a listener-scoped credential for the wrong listener. The operation should fail according to the contract, without returning the other person's private records.
Test read and write boundaries separately. A rejected read does not prove that a write route checks ownership correctly. Include the token-minting step if your own backend maps application accounts to external listener IDs.
Keep this testing inside systems and accounts you control. Do not search for real customer IDs or probe unrelated workspaces.
Inspect the application layer too
Your provider can enforce workspace isolation while your own cache or proxy still mixes accounts. Send the controlled requests through the same backend route, session handling, and cache path used by the product.
Switch accounts while an earlier response is in flight. Confirm that a correct response for A cannot appear on B's screen after the switch.
Record which boundary each test proves: provider tenant scope, your account mapping, or your cache ownership. That makes the result more useful than a broad statement that the application is “secure.”
Keep fixture credentials private and clean up exact test records after completion. The test report needs account labels and outcomes, not plaintext tokens.