Create a private integration token

Prepare the integration request

Before creating a credential, identify the integration owner, destination sub-account, business purpose, required data, expected request rate, retention period, incident contact, and retirement date. This makes the scope review concrete and gives the business a record of why access exists.

• Use a name that identifies the system and owner, such as Support reporting server.
• Prefer read-only scopes for reporting, retrieval, synchronization, and validation.
• Do not select a broad category merely because the integration might use it later.
• Set a finite expiration for temporary work and a rotation schedule for long-lived services.
• Choose a rate limit based on measured need rather than the maximum value.

Create the credential

1. Sign in, choose the exact destination sub-account, and open Settings.
2. Select Developers and confirm that private integration management is enabled.
3. Select New private integration.
4. Enter an integration name, optional expiration, and requests-per-minute limit.
5. Search tools and abilities, review the risk badge and description, and select the minimum scopes.
6. Submit the form and review the credential summary.
7. Copy the one-time token directly into an approved secret manager.
8. Copy the MCP configuration or REST base and test the connection before closing the panel.

Protect the one-time token

Lead360 displays the token once and stores a one-way hash. It cannot show the same secret later. Do not paste the token into Ask360 chats, support tickets, source files, screenshots, memory documents, playbooks, kit archives, analytics, or ordinary application logs.

Place the credential in a dedicated secret manager or encrypted deployment secret. Restrict access to the runtime identity that needs it, prevent command tracing from printing it, redact authorization headers, and rotate immediately after suspected exposure.

Verify before production use

1. Call the version 2 status endpoint with Bearer authentication.
2. Confirm authenticated is true and the location matches the intended destination.
3. Compare returned scopes with the approved integration request.
4. Search operations and confirm that unrelated operation groups do not appear.
5. Run one controlled read using non-sensitive test data where possible.
6. Verify rate-limit headers and error handling before increasing traffic.
7. Record the key identifier, owner, creation date, expiration, and rotation date without recording the secret.

Handle later scope changes as a new access decision

Do not quietly expand an established token when the integration gains a new feature. Document the new purpose and fields, review the destination system, select only the additional required scopes, and repeat discovery and negative-access tests. A separate credential is usually clearer when the new workflow has another owner, environment, retention rule, or risk profile.

After creation, the integration list is the operational record for status, expiration, rate limit, last use, rotation, and revocation. Review it against the secret manager and deployment inventory so abandoned credentials are found before they become permanent background access.