V2 API returns 429 rate limit during client.connect() after fresh OAuth flow

[kozy-codes]

Problem

After successfully completing OAuth flow and obtaining a fresh access token, the V2 API authentication fails with a 429 rate limit error during client.connect().

Steps to Reproduce

1. Run ticktick-sdk auth --manual with fresh OAuth credentials
2. Successfully complete OAuth flow → obtain new access token
3. Set environment variables with new credentials:
   • TICKTICK_CLIENT_ID
   • TICKTICK_CLIENT_SECRET
   • TICKTICK_ACCESS_TOKEN (fresh token)
   • TICKTICK_USERNAME
   • TICKTICK_PASSWORD
4. Initialize client: client = TickTickClient.from_settings()
5. Call await client.connect()

Error

Failed to initialize V2 client: Authentication failed:  | Details: {'status_code': 429, 'response': '', 'requires_2fa': False}

TickTickConfigurationError: Both V1 and V2 APIs are required. V2 initialization failed: Authentication failed:  | Details: {'status_code': 429, 'response': '', 'requires_2fa': False}; V2 authentication verification failed

Full Traceback

Traceback (most recent call last):
  File "/Users/kj/clawd/skills/ticktick/scripts/tt.py", line 265, in <module>
    asyncio.run(main())
  File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
  File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
  File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
  File "/Users/kj/clawd/skills/ticktick/scripts/tt.py", line 221, in main
    await tasks_today()
  File "/Users/kj/clawd/skills/ticktick/scripts/tt.py", line 106, in tasks_today
    await tasks_for_date(date.today(), "today")
  File "/Users/kj/clawd/skills/ticktick/scripts/tt.py", line 58, in tasks_for_date
    await client.connect()
  File "/Users/kj/agents/ticktick-sdk/src/ticktick_sdk/client/client.py", line 131, in connect
    await self._api.initialize()
  File "/Users/kj/agents/ticktick-sdk/src/ticktick_sdk/unified/api.py", line 336, in initialize
    raise TickTickConfigurationError(...)

Context

• V1 OAuth completed successfully
• Fresh access token obtained via ticktick-sdk auth --manual
• 429 error occurs specifically during V2 API authentication/verification
• Happens immediately after OAuth flow (within seconds)

Expected Behavior

Client should initialize successfully with fresh credentials, or provide clearer error messaging about rate limits and retry strategy.

Questions

1. Should there be retry logic with exponential backoff for 429 errors during initialization?
2. Is the V2 authentication hitting rate limits because we just completed OAuth flow moments before?
3. Should the SDK cache/reuse authentication to avoid hitting limits during rapid reconnects?

Environment

• Python: 3.12
• ticktick-sdk: latest from local clone (/Users/kj/agents/ticktick-sdk)
• OS: macOS

[ConstantinHvber]

I'm experiencing the same thing, until yesterday everything worked perfectly now I cannot use V2 anymore

[mattpetters]

same here :(
is it over-sending requests? anyone try with curl? wondering if they changed the API reqs

[mattpetters]

@dev-mirzabicer

[MikeeI]

Workaround: V2 Session Caching

We hit the same issue. The root cause is that client.connect() does a full V2 login (username/password → /api/v2/user/signon) on every invocation. TickTick rate-limits this endpoint aggressively.

Quick fix we implemented:

1. After the first successful connect(), serialize the V2 session token to disk:

session_data = client._api._v2_client.session.to_dict()
session_data["device_id"] = client._api._v2_client._session_handler.device_id
# Save to JSON file

2. On subsequent calls, restore the session without hitting the login endpoint:

from ticktick_sdk.api.v2.auth import SessionToken
session = SessionToken.from_dict(cached_data)
client._api._v2_client.set_session(session)

3. Only do a fresh login when the cached session expires or fails verification.

This reduces V2 login calls from "every CLI invocation" to "once per 24h". The V2 API itself is NOT rate-limited -- only the login endpoint. You can verify this by using browser cookies with curl while getting 429 on login.

When we were completely locked out by the 429, we manually imported the browser session cookie (t=... from ticktick.com dev tools) into our session cache file. This bypassed the login endpoint entirely and fixed it immediately. Will see if it holds for at least 2 days.

Ideally this should be built into the SDK -- connect() could accept an optional session cache path and handle persistence automatically.

[ConstantinHvber]

Lol its not rate limiting even though the error code implies so. I found the solution yesterday but was locked out of my gh account so I can only post it now:

Just switch the useragent from "Mozilla/5.0 (rv:145.0) Firefox/145.0" to "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"

nevertheless caching the session is a good idea still

[mattpetters]

Yeah I also came up a similar solution -- just opened a draft fix, feel free to take it/give feedback or close and fix how you'd like. Appreciate this sdk so much, thanks all

[DougX71]

Thank @mattpetters for the fix. It is working for me!