Standard OAuth 2.0 — nothing new to learn. Authorize → token exchange → claim retrieval, using the OAuth libraries you already have, on web and app alike.
# 1. Send the user to the BBaton authorize page GET https://bauth.bbaton.com/oauth/authorize ?client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI} &response_type=code&scope=read_profile # 2. Exchange the redirect code for a token POST https://bauth.bbaton.com/oauth/token Authorization: Basic base64(client_id:secret_key) grant_type=authorization_code&code={CODE} # 3. Fetch the claim with the token GET https://bapi.bbaton.com/v2/user/me Authorization: {token_type} {access_token} # Response — the claim only, no identifiers { "adult_flag": "Y" } // name: none · birth: none
Organized in real adoption order. New here? Start at Preparation. In a hurry? Jump straight to Integration.
Apply for API access → Client ID · Secret Key issuance, Redirect URL registration.
Read the doc → 02 · OverviewOAuth flow, return-value structure, session policy — the core concepts.
Read the doc → 03 · IntegrationAuthorize → callback → token exchange → claim handling. Parameter tables and code.
Read the doc → 04 · Login ButtonButton asset downloads plus copy and style guidelines.
Read the doc →No changes to your auth stack. Responses carry no names, birthdates, or phone numbers — only the claim your policy needs.
Send the user to the BBaton authorize page. With an active session, the code returns immediately.
GET bauth.bbaton.com/oauth/authorize
Exchange the redirect code for a token using Basic auth. Sessions last 24 hours by default.
POST bauth.bbaton.com/oauth/token
Fetch the claim with the token. The response is adult status — no identifiers included.
GET bapi.bbaton.com/v2/user/me
Most integration errors are redirect_uri mismatches. The registered value and request parameter must match to the letter.
Login success alone is not the end. You can call /v2/user/me only after the code → token exchange.
The Secret Key is used for Basic auth at token exchange. Never expose it in front-end code or app bundles.
Confirm request IPs and Callback URLs match your environment, and validate the flow on staging first.
Web via OAuth directly, WordPress via plugin, apps via SDK. Every path uses the same issued credentials.
Standard OAuth 2.0 — use the open-source libraries you already have.
No custom development — install the plugin and enter your settings.
Add the .aar / .framework, initialize, and invoke the flow natively in-app.
Your Client ID and Secret Key are issued automatically on application. Stuck mid-integration? We reply within 24 hours.