Lead360 Developer Platform overview

What the Developer Platform provides

The Lead360 Developer Platform gives an approved integration controlled access to one Lead360 sub-account. A private integration token is created from Developer Settings, bound on the server to the selected destination, and limited to the exact scopes chosen by an authorized administrator. The credential can use the version 2 REST API or the Lead360 MCP gateway without inheriting a user password or broad agency access.

The platform exposes a reviewed operation registry instead of treating every internal route as a public contract. An integration can search only the operations permitted by its token, inspect an operation input schema and risk classification, and directly execute supported read operations. Mutations remain inside the Lead360 draft, approval, and apply workflow.

Tenant binding and least privilege

Every private integration token stores its owning agency and location on the server. Bearer requests do not accept a location, tenant, database, endpoint, credential, or authorization value as an operation argument. This prevents a client from changing its own authority by placing another account identifier in a request body.

• One token belongs to one exact Lead360 sub-account.
• Only granted production scopes are visible through operation discovery.
• Service scopes also require the related product service to be enabled for that sub-account.
• Agency-owner abilities can be granted and managed only by the agency owner.
• A revoked, rotated, expired, suspended, or tenant-invalid credential fails authentication.

Production operation model

Registry 1.5.0 currently describes 143 reviewed production operations across contacts, conversations, calendars, opportunities, payments, campaigns, sites, CRM data, Ask360, and enabled Lead360 services. The response from discovery is filtered by the credential scopes and current service entitlement, so different tokens may see different operation lists.

Read operations

Green read operations with a reviewed adapter can execute directly. The result remains tenant-bound and includes the operation key, execution mode, location identifier, and structured result. Integrations should still minimize requested fields, cache only when lawful, and avoid exposing returned customer data in logs.

Write and consequential operations

Yellow and red operations are discoverable when the token has the required scope, but direct execution fails closed with approval_required. The public boundary does not let a remote client bypass Lead360 review cards, exact target selection, confirmation, or effect policy.

Recommended implementation sequence

1. Define the exact sub-account, data purpose, integration owner, and retention requirement.
2. Create a private integration token with only the scopes needed for that purpose.
3. Store the one-time credential in a dedicated secret manager and keep it out of source code.
4. Call the version 2 status endpoint and confirm the returned tenant and granted scopes.
5. Search authorized operations and fetch each typed contract before sending arguments.
6. Start with controlled read requests and handle rate limits, expired tokens, and unavailable operations.
7. Route any proposed mutation through the supported Lead360 approval workflow.
8. Monitor usage, rotate credentials on schedule, and revoke access when the integration is retired.