Login with ThreadzSocial

OAuth 2.0 authorization code flow for multi-tenant integrations. End users sign in on ThreadzSocial and consent; your app receives an access token scoped to that user only. Listing writes use the authorizing user as seller_id — same multi-account rule as API keys.

When to use OAuth vs API keys

API keys act as the developer account that owns the key (good for your own inventory or single-tenant tools). OAuth lets each ThreadzSocial seller connect your product and manage their rack.

Model

Piece	Detail
Grant	Authorization code (`response_type=code`). Refresh tokens optional later.
Client	Your developer app — `client_id` is the app UUID.
End users	Browser login + consent only. They never see your client secret.
Access token	Opaque bearer `stz_oauth_…` (hash stored; ~30 day lifetime).
API	Same as keys: `Authorization: Bearer …` on `/api/v1/*`. Also `GET /oauth/userinfo`.

Endpoints

URL	Purpose
`GET https://www.threadzsocial.com/oauth/authorize`	Login (if needed) + consent screen
`POST https://www.threadzsocial.com/oauth/token`	Exchange code for access token
`GET https://www.threadzsocial.com/oauth/userinfo`	Authorizing user profile (requires `read`)
`GET https://www.threadzsocial.com/api/v1/me`	Same credential works on the public API

Scopes

read — profile / me (default if scope omitted)
listings:write — create/update/archive listings as the authorizing user

Space-separated on authorize, e.g. scope=read listings:write.

Partner integration (5 steps)

Register an app at /developers/apps. Open the app → Tools & reference → Login with ThreadzSocial.
Generate a client secret (copy once) and add your exact https://… redirect URI(s). Client ID = app UUID.

Send the user to authorize:

Authorize URL

https://www.threadzsocial.com/oauth/authorize?response_type=code&client_id=YOUR_APP_UUID&redirect_uri=https%3A%2F%2Fyour-app.com%2Fcallback&scope=read%20listings%3Awrite&state=RANDOM_CSRF

Optional PKCE: code_challenge + code_challenge_method=S256.

Exchange the code on your server (never expose client_secret in the browser):

Token exchange

curl -sS -X POST https://www.threadzsocial.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "client_id=YOUR_APP_UUID" \
  -d "client_secret=stz_cs_…" \
  -d "code=stz_ac_…" \
  -d "redirect_uri=https://your-app.com/callback"

Response: access_token, token_type, expires_in, scope.

Call the API as that user:
Authenticated request
```
curl -sS \
  -H "Authorization: Bearer stz_oauth_…" \
  https://www.threadzsocial.com/api/v1/me
```
Listing POST/PATCH use the token user as seller. Store tokens securely; never log secrets.

Errors

Authorize page shows a friendly error when client_id / redirect_uri are invalid (does not redirect with secrets).
Deny → redirect with error=access_denied and state.
Token endpoint returns OAuth-style JSON: { "error", "error_description" } (not the { data } API envelope).

Security

Client secrets and access tokens are hashed at rest (SHA-256 + optional pepper).
Authorization codes are one-time and short-lived (~10 minutes).
Redirect URIs must match exactly; no fragments.
Use state for CSRF; prefer PKCE even for confidential clients.

Also see Authentication (API keys) and the API Terms of Use.