Security at Leadping

Understand how Leadping protects customer data through encryption, access control, isolation, monitoring, recovery, and shared responsibility.

Leadping applies multiple safeguards to lead intake, consent evidence, conversations, phone configuration, integrations, and account data. No single control carries the entire security model.

Control overview

Area	Leadping approach
Encryption in transit	Supported client, API, webhook, and service traffic uses HTTPS/TLS where Leadping controls the connection
Encryption at rest	Managed storage and infrastructure protections encrypt customer data at rest
Authentication	Users, API clients, agents, and sources must present the appropriate identity or credential
Authorization	Access is scoped by organization, role, credential, and resource
Tenant separation	Organization context and authorization checks separate customer records
Secrets	Keys, tokens, signing secrets, and connected-system credentials receive dedicated handling
Monitoring	Service health, authentication, provider, delivery, abuse, and suspicious-activity signals are monitored
Auditability	Security-relevant events support troubleshooting, review, and investigation
Recovery	Backup and recovery practices support service continuity

Leadping does not publish implementation details that would materially increase attack risk.

Encryption and data movement

Customer data is encrypted in transit using HTTPS/TLS and at rest using managed infrastructure protections. Encryption operates alongside authentication, authorization, isolation, monitoring, and restricted production access.

Customers must use HTTPS for systems they control, including posting integrations and webhook receivers. Exported data is no longer protected by Leadping access controls and must be secured by the customer.

Access and isolation

• User access follows organization membership and role.
• API access follows the authenticated user, organization, agent, or source context.
• Resource checks prevent a valid credential from receiving unrelated access.
• Production access is restricted to authorized personnel and providers with a business need.
• Access can be revoked, rotated, or restricted when risk is detected or access is no longer required.

Customers control who they invite, which permissions they grant, and which external systems they connect.

Credentials

Treat API keys, source keys, access tokens, refresh tokens, webhook secrets, and integration credentials as confidential.

• Store secrets in protected runtime configuration or a secret manager.
• Use separate credentials when traceability or independent rotation matters.
• Grant only the required access.
• Rotate exposed or misdirected credentials immediately.
• Never place secrets in lead metadata, URLs, screenshots, support messages, analytics, or public repositories.

Leadping may revoke, rotate, restrict, or disable credentials to protect customers, recipients, providers, and the platform.

Monitoring and response

Leadping records and monitors security-relevant signals needed to operate and protect the service. Depending on the event, those signals may include authentication, API behavior, provider feedback, delivery behavior, suspected abuse, and unusual usage.

When investigating an incident, Leadping works to:

1. contain the issue;
2. protect affected systems and accounts;
3. preserve useful evidence;
4. restore normal operation; and
5. make notifications required by applicable obligations.

No online service can guarantee absolute security. These controls are designed to reduce risk, detect problems, and support responsible response.

Service providers

Leadping uses established providers for infrastructure and platform functions. Provider access is limited to the role needed to deliver the service. See Subprocessors.

Customer responsibilities

Customers should:

• protect credentials and account-recovery channels;
• review users and roles regularly;
• remove access promptly when it is no longer needed;
• secure forms, publishers, CRMs, webhooks, exports, and local copies;
• validate webhook signatures;
• collect only the information needed for the workflow; and
• report suspected access or credential exposure quickly.

For implementation guidance, see API Authentication and Webhook Validation.

Report a concern

Email [e-mail] with the affected business or system, approximate time, and what you observed. Do not send passwords or complete credentials.

Review Responsible Disclosure before conducting any testing.