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

Question

GoalI 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 uncertaintyAPI 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.QuestionsIs 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?

Tasadduq Burney · Answer

To test qTest Manager REST API integrations without risking production data, the supported method is to create a separate sandbox project and generate a dedicated API token from a least-privilege service account. qTest does not provide a built-in "dry run" or staging mode for its API; all requests are executed against the project specified in the endpoint path.

Sandbox vs. Production Constraints
While sandbox or trial projects generally provide access to the same endpoints as production tiers, there are two primary areas where behavior may diverge:

Rate Limits: Trial or lower-tier instances may enforce stricter rate limits (e.g., 60 requests per minute). High-frequency CI pipelines may trigger 429 Too Many Requests errors in a sandbox that would not occur in a fully licensed production environment.
  Feature Parity: Certain advanced features, such as custom fields or specific reporting modules, may be disabled in trial projects, potentially causing 400 Bad Request errors if your integration attempts to write to non-existent custom attributes.

CI Strategy: Auto-Creation vs. Pre-Planned Runs
For pipelines running multiple times per day, the choice between auto-creating runs and mapping to pre-planned runs involves a trade-off between traceability and system overhead.

Strategy
      Pros
      Cons

Auto-Creating Runs
      Perfect isolation per build; full historical traceability.
      High object churn; increased risk of hitting rate limits.

Pre-Planned Runs
      Lower API overhead; cleaner project hierarchy.
      Requires stable Test Case IDs; harder to isolate specific build failures.

Implementation and Verification
To verify the integration safely, follow these steps using a service account assigned a "Tester" role limited strictly to the sandbox project:

Authenticate: Use the API token to obtain an access token via the OAuth endpoint. Note that the path may vary (e.g., /api/v3/oauth/token) depending on your qTest version.
  Create Run: Execute a POST to /api/v3/projects/{projectId}/test-runs to ensure the token has creation permissions.
  Submit Result: Execute a POST to /api/v3/test-runs/{runId}/test-cases/{tcId}/results.
  Verify Scope: Confirm in the qTest UI that the results appear only in the sandbox project and not in production.

Diagnostic Note: To provide a more specific endpoint recommendation, please confirm if your instance is qTest SaaS or an on-premise deployment, as authentication headers and version paths can differ.

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

Goal

Constraints and uncertainty

Questions

1 answer

Sandbox vs. Production Constraints

CI Strategy: Auto-Creation vs. Pre-Planned Runs

Implementation and Verification

Your perspective belongs here.

0 question comments

Strategy	Pros	Cons
Auto-Creating Runs	Perfect isolation per build; full historical traceability.	High object churn; increased risk of hitting rate limits.
Pre-Planned Runs	Lower API overhead; cleaner project hierarchy.	Requires stable Test Case IDs; harder to isolate specific build failures.