GET /v1/auth/google/start

This endpoint is the entry point of the console's Google OAuth login flow. It is not a JSON API — it is a full-page navigation target. The browser is meant to land here directly (via window.location.assign), and the server responds with a 302 Found redirect to Google's OAuth consent screen.

Before redirecting, the server generates a random CSRF state value and a PKCE code verifier, stores both in short-lived HttpOnly cookies, and builds the Google authorization URL with a PKCE S256 challenge and the openid email profile scopes. Google then sends the user back to GET /v1/auth/google/callback, which validates the state, exchanges the authorization code, and issues the nl_session / nl_csrf cookies.

Because this is a browser redirect and not an XHR/fetch call, do not call it with fetch expecting a JSON body — point the top-level window at it instead. If Google OAuth is not configured on the server, the endpoint redirects to /login?error=google_disabled rather than returning an error body, so the user never sees raw JSON.

This endpoint takes no path params, query params, or request body.

On success the server returns a 302 Found to the Google consent screen and sets two short-lived cookies:

When Google OAuth is not configured server-side, the response redirects to the login page instead — no cookies are set:

HTTP/1.1 302 Found
Location: /login?error=google_disabled

Response fields

There is no response body. The meaningful output is the Location header and the two Set-Cookie headers.

The Google authorization URL carries these fixed query parameters: response_type=code, scope=openid email profile, code_challenge_method=S256, access_type=online, and prompt=select_account.

This endpoint never returns a JSON error envelope — every outcome is a redirect.

The frontend reads the ?error=google_* query parameter on /login and shows a toast via the auth.google.disabled i18n key; downstream callback failures arrive as ?error=google_<tag> (e.g. google_invalid_state, google_exchange_failed).

JavaScript (fetch)

// Do NOT fetch() this endpoint — it is a redirect, not a JSON API.
// Trigger the OAuth flow by navigating the top-level window:
function signInWithGoogle() {
  window.location.assign('https://api.triport.io/v1/auth/google/start');
}

TypeScript SDK (@triport/sdk)

import { authUrl } from '@triport/sdk';


// The SDK exposes the start URL; the actual redirect must happen in the browser.
window.location.assign(authUrl('/v1/auth/google/start'));

Python (triport-sdk)

# Google OAuth login is an interactive browser flow and cannot be completed
# from a headless server-side client. Open the start URL in a browser instead:
import webbrowser


webbrowser.open("https://api.triport.io/v1/auth/google/start")

• The nl_google_state and nl_google_verifier cookies are scoped to Path=/v1/auth/google/, so they are only sent on the /start and /callback requests — they are cleared as soon as the callback consumes them, regardless of outcome, and expire on their own after 10 minutes.
• These are distinct from the long-lived session cookies (nl_session + nl_csrf) that are issued only after a successful callback. See the authentication overview for how the session cookies work.
• Related: GET /v1/auth/google/callback completes the flow; POST /v1/auth/email/start and the wallet challenge/verify endpoints are the other ways to begin a console session.