BrowserStack REST API retries and CI result reporting: preventing duplicate session entries and artifact uploads

Short answer

No — as of the 2024-era Automate REST API, there is no supported mechanism to link a retried session to its original. A retry creates a brand-new session with a fresh session_id, and there is no documented idempotency key, continuation flag, or parent-session field you can rely on. Artifact uploads cannot be suppressed or deduplicated via the API: video, logs, and screenshots are generated per session. The retry limit (commonly described as up to three per original session) is enforced server-side, is plan-dependent, and is not configurable through the REST API. There is no documented difference in enforcement between UI-triggered and API-triggered retries — assume both hit the same server-side limit until BrowserStack support confirms otherwise for your account.

Likely explanation vs. confirmed facts

The duplication you see is expected behavior, not a misconfiguration. Each retry is an independent session in the dashboard and in API responses, with your test name, tags, and metadata copied verbatim. Because your collector keys ingestion on session_id, one logical test run necessarily appears multiple times. What is not confirmed — and you should not build on — is the existence of any undocumented field on the retried session referencing its predecessor. Undocumented fields can appear and disappear with platform updates.

What to do instead: correlate client-side

Since the platform won't group attempts for you, carry a stable identifier you control and group in your collector:

1. Generate a logical run ID in CI (e.g., a UUID per test execution) and inject it into the build name, a tag, or custom metadata before the first attempt. Because retry copies metadata verbatim, every attempt inherits it automatically.
2. Log every attempt: session_id, logical run ID, status, timestamps. This preserves full attempt history.
3. Change your collector's primary key from session_id to the logical run ID, storing attempts as children of one run. Keep the final (or latest passing) attempt as the canonical result; retain earlier attempts as history or discard per retention policy.
4. Handle artifact storage in your pipeline, not the API — e.g., only persist artifacts for the canonical attempt, or apply retention rules to failed-attempt artifacts.

Verification steps

• After a retry, fetch both session objects via the API and diff them: confirm a new session_id and check whether any field references the prior session (don't depend on it, but know what's there).
• Group sessions in the BrowserStack dashboard by build name to see how retries cluster visually.
• Add CI logging of session_id + logical run ID per attempt to confirm metadata is copied unchanged.
• Confirm your plan's actual retry limit with BrowserStack support — it is plan-dependent and can change.

One caveat

Correlating by test name or build name alone is fragile if those values repeat across runs; a unique per-execution logical run ID avoids that. Also note that retry semantics and available fields differ between Automate (Selenium) and App Automate — if you use App Automate, verify the session fields against that product's current docs before finalizing the grouping logic.