Skip to Main Content

Authentication Overview

How to authenticate against Shoonya, and what to know before you start.

Overview

Every Shoonya API call runs against an authenticated session. Shoonya issues a Acesstoken after a successful login, which you attach to every subsequent request. There is no separate long-lived API key model — the token itself is your credential for the trading day.

How to authenticate

All integrations
Manual Login (OAuth) — see guide
Ending a session

OAuth is currently the only supported login flow — there is no TOTP auto-login and no separate token-renewal endpoint. See Manual Login (OAuth) for the full authorize URL, redirect handling, and checksum reference.

Session lifetime

Sessions are valid for the trading day and are invalidated at the daily server reset, regardless of activity. Since there's no renewal call, build your automation to re-run the full OAuth login flow once per day rather than assuming a persistent long-running token — see Manual Login (OAuth) for how to automate this.

ConventionEvery endpoint in this documentation that requires auth expects the token as a Bearer header: Authorization: Bearer <Acesstoken>.

Security notes

  • Never hardcode client_id, secret_code, or the OAuth code/checksum in source control — load them from environment variables or a secrets manager.
  • Treat Acesstoken as a bearer credential with the same sensitivity as a password: don't log it, don't put it in error messages sent to third-party monitoring tools.
  • If you suspect a token has leaked, call Logout immediately to invalidate the session rather than waiting for the daily reset.

Notes

OAuth-specific security considerations (state parameter, PKCE, redirect URI validation) are covered on Manual Login (OAuth).