Use the base URL and capability export from your own Seedly CRM installation. The installed package determines which routes are available. A scope name in this reference does not grant access by itself.
Choose a credential
Standard v2 API key
A machine credential for a server you control. It is approved for one active client location, an explicit set of scopes, and the exact routes in its saved policy. Keep the key on your server and send it as a Bearer token.
Authorization: Bearer sk_live_...Connected App with OAuth
A confidential external app registered by the agency owner. An authorized user approves a separate connection for each location. Effective access is limited by installed capabilities, the app registration, the approved grant, and the user's current role.
Authorization: Bearer <opaque_access_token>A Standard key is not an OAuth session. An OAuth token is opaque and must not be decoded or treated as an API key. Both new models enforce their own route allowlists and location boundaries.
OAuth connection
- The installation operator registers the app, its exact HTTPS callback, available locations, and maximum scopes. Use a separate registration for staging and production.
- Obtain the app's Copy connection setup export and receive its client secret through a separate secure channel. The export includes the issuer, protocol endpoints, API base URL, and configured scope definitions. It contains no secret or customer data.
- Start each authorization with a fresh state value and S256 PKCE challenge. Bind them to the initiating session and exact callback. Request only the scopes the app needs, plus
offline_accesswhen renewal is needed. - After the user selects and approves one location, verify state and exchange the single-use code using HTTP Basic client authentication and a form-encoded body. Store the returned connection and location IDs with the access and refresh tokens.
Resolve route paths against the origin of the exported API base URL. Do not append /api/v1 twice. The issuer's discovery, authorization, token, revocation, and introspection endpoints are installation-specific. Do not substitute a branded location domain for the canonical issuer.
Access tokens expire according to expires_in. Refresh tokens rotate on successful renewal; serialize refreshes per connection and save the replacement pair atomically. If a refresh response is uncertain, recover the saved replacement or reconnect. Reusing an old refresh token can revoke that location connection.
Scopes and policy versions
Read, write, delete, send, publish, execute, export, and administrative scopes are separate approvals. A familiar resource name does not imply its sibling permissions. Each capability maps an exact HTTP method and path to a scope and policy version. When a route, field class, or side effect expands, the scope policy version changes and an existing OAuth grant needs fresh approval.
Own, team, and selected-record grants are available only on explicitly marked contact, task, and opportunity operations. Some actions need additional record-policy approvals, such as reassignment, lifecycle changes, or restricted webhook delivery. The catalog lists supported modes and minimum versions for each operation. Location-wide routes do not become record-filtered merely because a related scope supports filtering.
Agency and personal authority version 1 require separate enrollment. Existing location grants and keys do not inherit them. Agency-wide app availability also does not turn one location token into an agency-wide token.
Test credentials simulate provider delivery only on documented message routes. Other authorized writes can change data or trigger configured effects. Treat test mode as a limited integration mode, not a dry run.
The OAuth-only messages:replies:read scope reserves an app-owned SMS reply route, but that route currently returns 403 while sender ownership is audited. App social publishing, retry, scheduling, and scheduled-post approval also remain held until live provider acceptance. A listed scope is not a promise that a held operation can run. Native staff actions and existing legacy integrations retain their current behavior.
Legacy compatibility
Existing unversioned and Legacy v1 keys, agency keys, and CloseBot integrations keep their published parsing, permission, response, and retry behavior. They are not converted or rotated into Standard v2 or OAuth automatically. A new header or token spelling does not upgrade a legacy key. Existing grants cannot gain routes through refresh or key rename.
The existing CRM REST API endpoint guides remain available. For new-model access, check the installation's OpenAPI file and exported capability subset before calling an endpoint.