qTest API result submission in CI: limits on testing the integration without production credentials

Goal

I want to exercise our CI pipeline's integration with the qTest Manager REST API — creating test runs and submitting automated test results — without using production credentials or writing results into our live project. The plan is a separate sandbox or trial project with its own API token, generated by a least-privilege account, so a leaked token in CI logs has limited blast radius.

Constraints and uncertainty

API tokens inherit the generating user's permissions, so the sandbox account's access must be scoped carefully. I also understand endpoint paths and authentication header formats have differed across qTest releases and between SaaS and on-premise deployments, so any example I follow must match our target instance — I have not confirmed which API version our instance exposes. Sandbox or trial tiers may also impose rate limits or feature restrictions that differ from licensed production, which could make integration test results unrepresentative.

The bigger open decision is structural: the API appears to support both auto-creating test runs and cycles per build and mapping results onto pre-planned runs. Each choice affects traceability and reporting differently, and I am unsure which fits a pipeline that runs many times per day.

Questions

• Is a separate sandbox project with a dedicated API token the supported way to test result submission, or does qTest offer a built-in test/staging mode for the API?
• Do trial or sandbox instances restrict the result-submission endpoints or rate limits compared with production tiers?
• For high-frequency CI builds, what are the trade-offs between auto-creating test runs per build versus mapping results to pre-planned runs?