Authentication and scopes

Create an API key, choose its scopes and role, act as a teammate, and keep keys safe.

Every request carries an API key. A key is a deliberate, narrow grant: it can do only what its scopes and its role allow, and every change it makes is recorded against it.

#Create a key

  1. Open Settings → API. Only owners and admins manage keys.
  2. Name the key for what it is used for, such as "Order sync".
  3. Choose its scopes, its role, an optional expiry and its requests-per-minute limit.
  4. Copy the key. It starts with sk_live_. We store only a hash, so a lost key cannot be recovered: revoke it and make another.
bash
curl https://synconone.com/api/v1/pipelines -H "Authorization: Bearer sk_live_YOUR_KEY"

A missing, wrong, revoked or expired key answers 401. A workspace that is not on Pro or Enterprise answers 403 to every key.

#Scopes

A scope names a kind of access. A write scope includes the matching read. A call that needs a scope the key lacks answers 403 and names the scope it needed.

ScopeAllows
people:readRead customers
people:writeCreate and change customers
companies:readRead companies
companies:writeCreate and change companies
leads:readRead leads
leads:writeCreate and change leads
opportunities:readRead opportunities
opportunities:writeCreate and change opportunities
tasks:readRead tasks
tasks:writeCreate and change tasks
notes:readRead notes
notes:writeCreate and change notes
records:readRead custom object records
records:writeCreate and change custom object records
pipelines:readRead pipelines and stages
evidence:readRead evidence
reports:readRun reports
webhooks:readRead webhook endpoints
webhooks:writeManage webhook endpoints
team:readRead teammates
tickets:readRead support tickets
tickets:writeOpen and change support tickets
meetings:readRead meetings
meetings:writeSchedule, change and cancel meetings
conversations:readRead live chat conversations
conversations:writeReply in, assign and manage live chat conversations

#Roles and acting as a person

Scopes are not the only gate. Every key also has a role, and a call must be something that role could do in the app. A key with the viewer role and a write scope can still not write, because a viewer cannot write in the app either. Keys can hold the admin, manager, member or viewer role, never owner.

A key can also act as one teammate. It then sees exactly what that teammate sees: their role, their teams and which records are visible to them. Fields hidden from that role are absent from responses, and records they cannot see answer 404, as if they did not exist. Use this for a key that belongs to one person's automation.

Replies sent in the live chat inbox and meetings scheduled through the API are made as the person the key stands for: its creator, or the teammate it acts as.

#Keeping keys safe

  • One key per job, with the fewest scopes it needs. Revoke a key the day it is not.
  • Keep keys in environment variables or a secrets manager, never in a repository, a browser or a mobile app. A browser is not a safe place for a key.
  • Set an expiry on keys given to contractors or trials.
  • Every change a key makes is recorded with the key's name and prefix, so what a leaked key did can be traced.