Developer documentation · Preview

Connect a site in four steps.

OAuth 2.1 authorization is planned, but real client registration and token exchange are not enabled yet. These examples document the expected server contract.

1. Register your application

Use a verified Pratama developer account. Set an exact HTTPS callback URL, a public privacy policy, application name and allowed scopes. Do not accept wildcard redirect domains or open redirects.

2. Create a PKCE challenge

Create a random code verifier in the client host and its SHA-256 challenge, and store a unique state and nonce. Only the requesting client may associate the callback with its pending sign-in attempt.

GET /oauth/authorize?response_type=code
  &client_id=REGISTERED_PRATAMA_APP
  &redirect_uri=https%3A%2F%2Fstudio.example.com%2Fcallback
  &scope=openid%20profile
  &state=FRESH_RANDOM_STATE
  &code_challenge=S256_CHALLENGE
  &code_challenge_method=S256

3. Prove Char.social ownership

Pratama issues a single-use, expiring code. The account owner places it in a public Char.social post/profile. The server verifies the exact code against the provider's public account ID using a server-owned API credential, never the user's secret. Account ownership claims and replay are audited.

4. Review consent and return

After the user approves, Pratama issues a short-lived authorization code. Exchange it server-to-server using the code verifier and validate issuer, audience, nonce, scopes and expiry. Native Char.social OAuth is not implied or supported.

POST /oauth/token
grant_type=authorization_code
code=ONE_TIME_PRATAMA_CODE
code_verifier=ORIGINAL_RANDOM_VERIFIER
redirect_uri=EXACT_REGISTERED_CALLBACK

Unavailable: Live /oauth/authorize, /oauth/token, client registration, discovery and identity verification. Calls currently return HTTP 503. No customer account data is processed.