FusionAuth Test Tenant vs Limited-Scope API Key for Refresh Token Rotation

Integration test credential strategy for FusionAuth refresh token flows

I need to test an OAuth integration without using production API credentials. The two documented options are a dedicated test tenant with a test API key, or a limited-scope API key created inside the production tenant. Behavior may vary by FusionAuth version, so the deployed release should be confirmed before relying on either path.

The test tenant isolates data but is described as invalidating refresh tokens after a single use and issuing access tokens with a fixed expiration. The limited-scope key remains in the production tenant and inherits the configured token TTL and refresh-token reuse policy, but it can expose real user data if scopes are misconfigured. Test tenant data may also reset periodically, which affects tests that depend on persistent attributes.

Because refresh token rotation differs between the approaches, I need to determine which option reproduces production-like rotation while keeping test data separate and avoiding accidental production writes.

Does the test tenant’s single-use refresh token invalidation match production rotation behavior? Can a limited-scope API key safely exercise refresh token flows without risking writes to production user data? Which approach better preserves the production token TTL and rotation semantics during pre-release validation?