Developer support and security responsibilities

Lead360 platform controls

• One-time credential display with one-way hashed secret storage.
• Server-side sub-account binding and location-only scope catalog.
• Credential status, expiration, rotation, revocation, and platform suspension checks.
• Per-key throttling with limit, remaining, reset, and retry headers.
• Scope and service-entitlement filtering for operation discovery.
• Typed argument validation and rejection of authority-related fields.
• Direct execution limited to reviewed reads with fail-closed mutation approval.
• Durable authentication and key-management events.

Customer and developer responsibilities

The customer chooses the integration purpose, destination sub-account, scopes, administrators, external systems, data retention, and downstream access. The developer must protect credentials, use only documented contracts, validate responses, minimize data, honor rate controls, and avoid attempts to bypass tenant or approval boundaries.

Review the Terms and Conditions, Privacy Policy, Data Processing Addendum, Acceptable Use Policy, Security information, and retention guidance before production use. Additional agreements or technical restrictions may apply to health information or other regulated data.

Minimum integration security baseline

Use a maintained server environment, supported TLS libraries, restricted outbound networking, dependency and image scanning, prompt security updates, encrypted secret storage, multi-factor administrator access, role-based production access, and monitored deployment changes. Separate test data and credentials from production and prevent developers from downloading unrestricted customer datasets to personal devices.

Define alerts for repeated failed authentication, sudden request-volume changes, unusual operation groups, large exports, and use after the expected retirement date. Test credential rotation and emergency revocation before launch so the response does not depend on one unavailable administrator.

Review third-party libraries and hosting providers that can observe request metadata or response data. Document their access, location, retention, deletion, incident notice, and subprocessor terms before sending Lead360 customer information through them.

Repeat this vendor and security review at least annually and before any material integration expansion.

Prohibited implementation patterns

• Embedding a private token in browser code, mobile application assets, public repositories, or downloadable files.
• Sharing one token across unrelated customers, sub-accounts, environments, or integration owners.
• Adding tenant, credential, database, server, endpoint, or arbitrary URL authority to operation arguments.
• Calling undocumented internal routes to avoid scopes, risk classification, or approval.
• Logging full Authorization headers, payment data, customer messages, or unrestricted response bodies.
• Using returned data for an incompatible purpose or retaining it without a documented requirement.
• Treating generated recommendations as guaranteed facts or autonomous consequential decisions.

Request technical support

Contact [email protected] with the destination sub-account name, public key identifier, timestamp and timezone, endpoint path, client and library version, operation key, HTTP status, structured error code, and a redacted request summary. State whether status and operation discovery succeed.

Do not send the private token, Authorization header, secret-manager screenshot, customer message, payment details, complete API result, or unrelated personal data. Lead360 Support does not need a credential to investigate the public contract.