Get Consent Context
GET/v1/open-api/oauth/authorize
Everything the consent page needs to render itself: which application is asking, its logo, which grants it wants, and whether this employee already approved it.
This is not the browser-facing authorization endpoint. The URL an OAuth client is sent to is the consent page, which is a frontend route; the page then calls this API to fill itself in. Opening this path in a browser only yields
401.
Authenticated with the employee's CRM session token as
Authorization: Bearer <token>, not with an Open API token — the token is verified
against the core service on every call. No particular employee permission is needed:
being signed in is enough, because the company is taken from the verified token and
never from the request, so an employee can only ever consent for their own company.
The request is validated before anything is shown: response_type must be code, the
client_id must exist and not be suspended, the redirect_uri must be one the
application registered, and every requested grant must be within the application's
allowed set. A public client must also present a code_challenge.
code_challenge and code_challenge_method are echoed back unchanged so the page can
put them straight into the consent body without parsing the query string itself.
Request
Responses
- 200
- 400
- 401
- 429
Context for the consent page.
Invalid request (400). messageCode 6907 — response_type is not code,
the client_id is unknown, or a public client omitted code_challenge; 6902 —
the redirect_uri is not registered on the application; 6904 — a requested grant
is outside the application's allowed set; 6916 — the application is suspended.
Unlike the protocol endpoints, these responses use the standard envelope.
Missing or invalid employee CRM token (401, messageCode 6204).
Too many OAuth requests from this IP (429).