Developer Settings and permissions

Open the correct Developer Settings area

Sign in to Lead360, select the intended sub-account, open Settings, and choose Developers. The selected location is part of the credential authority. Creating a token while the wrong sub-account is open produces a credential for the wrong destination, even if the scope names are otherwise correct.

Developer Settings displays the MCP server URL, REST API base, authentication format, credential policy, scope catalog, and existing private integrations. The list shows names, status, access, rate limit, expiration, last use, and available management actions without displaying an existing secret.

Who can manage credentials

Access requires the selected location to be available to the signed-in user and either administrative authority or the Developers settings permission. A user cannot manage a credential for a location outside their membership. Lead360 also evaluates whether the credential includes an agency-owner-only service before allowing rotation or revocation.

Agency-owner-only service groups

Teams, Automations, Sites Builder, Ask Lead360, and Sales360 abilities are restricted to the agency owner when they are available. This protects service-level actions that can affect internal collaboration, automation execution, publishing surfaces, or specialized product behavior.

Owner-only does not mean unrestricted. The selected scope must still be production eligible, the token remains bound to one location, related service entitlements must be active, rate limits still apply, and direct mutations remain subject to approval controls.

Permission review checklist

1. Confirm the selected sub-account and integration owner.
2. Document the business purpose and data categories the client needs.
3. Search the scope catalog and select the smallest read scopes first.
4. Add a write-related scope only when a documented Lead360 approval workflow requires discovery of those operations.
5. Set an expiration and a rate limit appropriate to expected traffic.
6. Create the credential and store the one-time token immediately.
7. Test the status endpoint and inspect the returned scope list.
8. Review active integrations periodically and revoke unused access.

Repeat the review after access changes

Recheck the integration whenever the owner, destination sub-account, product entitlement, selected scopes, external vendor, or data purpose changes. Compare the integration list with active deployments and scheduled jobs, verify the last-used timestamp, and confirm that former team members cannot reach the secret manager. Create a smaller replacement credential when access can be reduced, then revoke the previous key after controlled verification.

The permission review should also confirm that returned data still has an approved destination, retention period, deletion method, and support owner. A technically valid token should not remain active when its business purpose or lawful data use has ended.