LeetCode GraphQL API Authentication and Rate‑Limit Constraints for CI/CD Automation

LeetCode’s public GraphQL API relies on a session cookie (LEETCODE_SESSION) for authentication, while CI/CD pipelines require a stable, token‑based mechanism for long‑running automation.

The goal is to enable unattended submission and result polling without manual re‑authentication or manual back‑off handling.

Current constraints include opaque cookie lifetimes that may expire without warning, undocumented rate limits that return 429 responses without Retry‑After, and submission status transitions that can remain in “Running” for 10–30 seconds with no webhook alternative. Additionally, two‑factor authentication invalidates cookie‑based access entirely, and no official password‑less token is provided.

How can automation sustain authentication across variable cookie expiration without triggering CAPTCHA? What reliable method exists to poll submission status when the “Running” state may stall indefinitely? Is there a supported way to retrieve granular test‑case execution metrics beyond aggregate values?