Skip to main content

​
Tokens

  • Treat access_token like a password. It’s shown once, in the POST /oauth/token response — Workchats doesn’t store it in a form you can retrieve again.
  • Send it only in the Authorization: Bearer header. A token in a query parameter (?token= or ?access_token=) is rejected with 400 token_in_query — Workchats won’t even read it from there, so it can’t leak into a server access log via the URL.
  • A bot token is scoped to exactly one company. It doesn’t expire, so treat a leaked token as a live incident: call POST /oauth/revoke immediately, then reinstall to get a new one.

​
Client credentials

client_id and client_secret authenticate your App itself, at POST /oauth/token and (optionally) POST /oauth/revoke. Keep client_secret server-side — never in a browser bundle, mobile app, or public repository. GitHub’s secret scanning and gitleaks-style tools recognize the wc_bot_live_ / wc_bot_test_ token prefixes, so a leaked token in a public repo gets flagged.

​
Scopes

Request only the scopes your integration needs. users:read.email in particular exposes people’s email addresses (subject to their own visibility setting) — don’t request it if you only need names and ids.

​
Callback signatures

Once callbacks ship (Phase 1b), verify every one’s signature before acting on it. See Callbacks & signature verification.

​
Transport

All API traffic and (once they ship) callback deliveries are HTTPS, TLS 1.2 or later. There’s no unencrypted option.