REST API quickstart

Requirements

• An active Lead360 sub-account and permission to use Developer Settings.
• A private integration token with the minimum required production scopes.
• A trusted server or approved development environment that can protect the credential.
• HTTPS access to app.lead360.io and JSON request support.
• A plan for timeouts, rate limits, retries, redaction, rotation, and revocation.

Verify the connection

Send a GET request to https://app.lead360.io/v2/subaccount-api/status with the Bearer token. A successful response proves the credential is active and reports the exact location and granted scopes. Stop when the destination does not match the integration record.

Read X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on authenticated responses. These values are specific to the key and help the client pace work before a 429 response.

Discover before executing

1. Call GET /operations and optionally filter by query, green, yellow, red, effect category, and limit.
2. Select an operation returned for the current credential instead of hardcoding an internal route.
3. Call GET /operations/{operation_key} to fetch its scope IDs, risk, execution mode, and JSON input schema.
4. Validate required properties and reject additional client-supplied fields.
5. Call POST /operations/{operation_key}/execute only for a direct_read contract.
6. Treat approval_required as a product workflow boundary, not a retryable technical error.

Request and response discipline

Use a 30-second or shorter connection timeout unless the documented operation requires otherwise. Retry temporary network failures and 429 responses with bounded backoff, but do not retry authentication, insufficient scope, invalid arguments, unavailable operations, or approval-required responses without correcting the cause.

Store only the data required by the integration purpose. Redact Authorization headers and customer content from logs. Do not copy complete responses into support tickets. When an integration synchronizes personal data to another system, the account owner remains responsible for an appropriate legal basis, destination security, retention, access requests, and deletion.

Prepare the production deployment

Run the client under a dedicated service identity with access only to the required secret and network destination. Separate development and production credentials, pin dependency versions, scan source and build output for embedded tokens, and configure alerts for repeated authentication, scope, rate, and adapter failures. Make the integration owner and rollback procedure visible to the operations team.

Before increasing traffic, test an expired or invalid token, a missing scope, an unavailable operation, invalid arguments, a rate-limit response, and an approval-required operation. The client should fail without exposing secrets, retrying permanently rejected requests, or substituting another endpoint.