Start
Authentication and credentials
Create, store, rotate, and revoke site-scoped credentials without crossing customer boundaries.
Use the correct credential
Concierge has separate credentials for separate trust boundaries. Ticket API keys authorize API operations for one site. Signing secrets prove webhook integrity. Optional CRM bearer tokens authenticate Concierge to middleware owned by the customer.
| Credential | Used for | Where it belongs |
|---|---|---|
| Site API key | Ticket API | Your server-side secret manager |
| CRM signing secret | CRM Webhook and CRM inbound HMAC | Both servers, never the browser |
| CRM bearer token | Optional middleware authorization | Both servers, never the browser |
| Concierge session | Creating and revoking access in the UI | Managed by the Concierge app |
Create a least-privilege API key
Open /sites/{siteId}/developers while signed in to the correct account. Name the integration so another operator can identify it, select only the scopes it needs, and create the key.
| Scope | Allows |
|---|---|
| tickets:read | List and retrieve tickets for the owning site. |
| tickets:write | Update tickets and add specialist comments for the owning site. |
| assessments:read | Poll public evidence assessments for the owning site. |
| assessments:write | Queue public evidence assessments for the owning site. |
Rotate without downtime
Use an overlap window so an integration never loses access while a secret is changing.
- Never expose cg_live_ values in client JavaScript, URLs, screenshots, logs, or repositories.
- Use a different key per environment and per site.
- Revoke access immediately after ownership, vendor, or support access changes.
- Create a replacement key with the same or narrower scopes.
- Deploy the replacement key to the external service.
- Run one read and, when applicable, one safe write.
- Confirm the replacement key's last-used time changes in Concierge.
- Revoke the old key and verify that it now receives 401.
Next guide
Public evidence assessments