Skip to main content
SocialAPI runs an OAuth 2.1 authorization server so that an MCP client or your own app can act for a SocialAPI user without handling an API key. The user approves the app on SocialAPI’s consent screen, and the app receives an access token it sends as Authorization: Bearer <token> to the MCP server at https://api.social-api.ai/mcp and to every public /v1 endpoint. Claude, ChatGPT, Cursor, and other MCP clients that support OAuth run this flow on their own once you add the server URL: see the MCP server. Build the flow yourself only for a client you write. The server follows RFC 8414 (metadata), RFC 7591 (dynamic client registration), RFC 7636 (PKCE, required), RFC 7009 (revocation), and RFC 9728 (protected resource metadata).

Endpoints

Every path is on https://api.social-api.ai, with no /v1 prefix and no API key.

Discover the server

The protected resource metadata names the MCP server and its authorization server:
Response (HTTP 200):
The authorization server metadata lists every endpoint:
Response (HTTP 200):

Run the flow

1

Register your client

Registration is open: any app can register, with no API key.
Response (HTTP 201):
client_name and at least one entry in redirect_uris are required, or the request returns 400 validation.field_required. Each redirect URI must use http or https and must not contain a user name, a password, or a #fragment; otherwise the request returns 400 validation.field_invalid. client_secret is shown once and never expires (client_secret_expires_at is 0).
2

Send the user to the consent screen

Generate a PKCE code verifier, derive its S256 challenge, and redirect the user’s browser to:
SocialAPI checks the request, then sends the user to the SocialAPI dashboard. The user signs in to SocialAPI, sees your client_name, and approves or denies. The consent screen accepts the request for 1 hour.A missing client_id, redirect_uri, or code_challenge returns 400 validation.field_required. A code_challenge_method other than S256 returns 400 validation.field_invalid. An unknown client_id returns 400 auth.oauth.invalid_client, and an unregistered redirect_uri returns 400 auth.oauth.invalid_redirect. These errors are JSON responses to the browser, not redirects.
3

Receive the code

After approval, the browser lands on your redirect URI:
When the user denies, the redirect carries error=access_denied and your state instead. The code expires 10 minutes after it is issued and works once.
4

Exchange the code for tokens

Response (HTTP 200):
code, client_id, and code_verifier are required. If you send client_secret, SocialAPI verifies it. If you omit it, PKCE alone protects the exchange. redirect_uri is checked when you send it, and must equal the one used in step 2. An exchange that passes the client_id and client_secret check still uses up the code when it fails because the code was issued to another client, redirect_uri does not match, or PKCE verification fails: send the user through step 2 again.
5

Call the API

Send the access token as the Bearer token:

Tokens

An expired or invalid access token returns 401 auth.invalid_token on /v1 endpoints. An access token whose user no longer exists returns 401 auth.user_not_found. For a key with narrower access, use a scoped API key instead.

Refresh the access token

The response (HTTP 200) has the same shape as the code exchange, with a new access token and a new refresh token. Store the new refresh token: the one you sent stops working. refresh_token and client_id are required. If you send client_secret, SocialAPI verifies it. If you omit it, the refresh token alone authorizes the refresh (PKCE does not apply to a refresh).

Client authentication

The token endpoint reads client_id and client_secret from the form body. It also accepts them with HTTP Basic authentication (Authorization: Basic base64(client_id:client_secret)); when both are present, the body wins. It accepts a JSON body when the request has no form-encoded grant_type. A client that cannot keep a secret, such as a desktop or browser app, can leave client_secret out: PKCE protects the code exchange.

Revoke a refresh token

Response: HTTP 200 with no body, whether or not the token existed (RFC 7009). The refresh token stops working when it belongs to that client_id. Revocation applies to refresh tokens only: an access token already issued keeps working until it expires, at most 1 hour later.

Token endpoint errors

/oauth/token answers errors in the OAuth format (RFC 6749), not in the SocialAPI error envelope:
  • 400 invalid_request: grant_type is missing, or a required parameter of the grant is missing.
  • 400 unsupported_grant_type: grant_type is not authorization_code or refresh_token.
  • 400 invalid_grant: the code or refresh token is unknown, expired, already used, or issued to another client, or the PKCE verifier or redirect_uri does not match. On a refresh, an unknown client_id also returns invalid_grant.
  • 401 invalid_client: on a code exchange, the client_id is unknown. On either grant, the client_secret you sent is wrong.
Last modified on October 13, 2026