OAuth 2.0 Authorization Code flow with PKCE, the recommended approach for connecting apps and services that act on behalf of a user. Desktop and CLI applications use this flow to obtain a token tied to a specific user's account without ever handling their password.
Call order:
- Register (
POST /oauth/register/) — obtain aclient_id(one-time, no auth required). - Authorize (
GET /oauth/authorize/) — open the browser to the consent URL. The user approves the consent screen in the dashboard. - Token (
POST /oauth/token/) — exchange the authorization code + PKCE verifier for an access token.
The access token is used as a Bearer credential in the Authorization header, the same way as an API key.
Open endpoint — no authentication required. Desktop/CLI apps call this once to obtain a client_id they persist locally and reuse for all future authorize flows.
List of allowed redirect URIs. At least one is required. The redirect_uri used in the authorization request must exactly match one of these.
- Productionhttps://api-dashboard.influencers.club/public/v1/oauth/register/
curl -i -X POST \
https://api-dashboard.influencers.club/public/v1/oauth/register/ \
-H 'Content-Type: application/json' \
-d '{
"client_name": "string",
"redirect_uris": [
"string"
],
"scope": "all"
}'Unique identifier for the registered client. Persist this value — it is required for all subsequent authorization requests.
Authentication method for the token endpoint. Always none (public client, PKCE required).
Supported grant types. Always [authorization_code, refresh_token].
{ "client_id": "string", "client_name": "string", "redirect_uris": [ "string" ], "scope": "string", "token_endpoint_auth_method": "string", "grant_types": [ "string" ], "response_types": [ "string" ], "client_id_issued_at": 0 }