Skip to main content
Send Leadping credentials in the Authorization header with the Bearer scheme:

​
Choose a credential

Do not interchange these credentials. In particular, a source key cannot access account, organization, user, analytics, setup, or other non-ingestion operations.

​
User access

Use a Leadping user access token only when the application operates as a signed-in user. Generated SDKs do not manage login, refresh, storage, or logout. Your application must obtain the token and attach it to the request adapter.

​
Agent access

Leadping supports WorkOS AuthKit Agent Registration with the service_auth identity type. The flow requires user approval:
  1. Register the agent with the user’s email address.
  2. Send the user to the WorkOS verification link.
  3. Complete the claim flow with the code shown to the signed-in user.
  4. Exchange the agent assertion for a short-lived access token.
  5. Send that token to Leadping as a Bearer credential.
The agent remains limited by the approved user’s organization membership, roles, and permissions. Use Leadping agent authentication and the discovery metadata below for current endpoints and request bodies. Store long-lived assertions and refresh tokens in an operating-system secret store. Do not persist short-lived access tokens unnecessarily.

​
Organization services

Use an organization API key for a conventional server integration that does not use Agent Registration.
  1. Open Leadping API Keys.
  2. Sign in and select the organization.
  3. Create a key and choose an expiration.
  4. Store the value immediately; Leadping displays the full key once.

​
Source intake

External posting systems use the key assigned to their source:
Source keys authorize only:
  • POST /leads
  • POST /leads/intake
See Send Leads with the Intake API for payload and validation requirements.

​
Verify the selected organization

With an organization API key or an authorized user token, make a read-only request before enabling writes:
Check that the returned organization is the one your integration is intended to use. A source key will not work for this check; confirm source-key access through a controlled intake submission instead.

​
Diagnose authentication failures

Confirm the header is attached by the final HTTP client, especially when a proxy or request adapter is involved. Inspect a redacted header name and scheme; never print the credential to diagnose the problem.

​
Replace an organization key

Create the replacement with the intended expiration, store it, and update the consuming service. Verify a read-only request and then revoke the old key. If the old key is exposed, revoke it immediately and restore the integration with a replacement. Source-key rotation differs: it invalidates the previous key immediately. Follow the source rotation procedure for that case.

​
Discovery metadata

A 401 Unauthorized response may identify the applicable resource metadata:

​
Protect credentials

  • Store credentials outside source code.
  • Transmit them only over HTTPS.
  • Never write them to logs, URLs, lead metadata, or error messages.
  • Scope each credential to the required organization and operation.
  • Rotate exposed credentials and revoke credentials no longer in use.
  • Keep SDK credential storage and refresh logic in your application infrastructure.
Continue with the SDK overview, API Reference, and rate-limit guidance.