Clientary
BUSINESS · COMMERCE & FINANCE
Clients, estimates, invoices and tracked hours from their own practice.
Connecting Clientary in practice
Every user in a Clientary account has their own token, and Clientary uses it for attribution — time tracked through the API is recorded against the staff user whose token made the call — so one shared service token misattributes every entry. The base URL is the customer’s own subdomain, and a request without Accept: application/json or a .json suffix does not get JSON.
Worth knowing
- The token is used as both username and password in HTTP Basic auth; the alternative is an OAuth 2.0 access token via the authorization code flow with PKCE, discoverable under /.well-known/.
- Because the token identifies the acting staff member, the choice of credential changes what the application’s own reports say about who did the work.
- Either the Accept header must be application/json or the resource URL must end in .json; JSONP is not supported, so a browser-side integration needs a proxy.
- The base URL is https://{yourdomain}.clientary.com/api/v2/…, so the account subdomain is effectively part of the credential and cannot be discovered from the token.
Checked against Clientary API introduction (2026-09-29)
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
Often connected alongside
Put Clientary behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.