One-time keys, stored as hashes
Production and trial keys are revealed once. LeadProof stores a SHA-256 key hash and a short prefix for identification, not the complete key.
Security and data handling
Protect the handoff without creating another payload archive.
LeadProof limits production destinations, hashes access credentials, fingerprints delivery requests, and verifies billing events before access changes. Every statement below is bounded to a control in the product.
Keep the source of truth in the authorized source system. Keep only the delivery evidence LeadProof needs.
LeadProof is a delivery reliability layer, not a CRM or long-term lead store. The production path processes approved fields for delivery and retains metadata and fingerprints for idempotency, receipts, support, and safe replay.
Implemented controls
Six controls a technical buyer can inspect.
Public HTTPS only
Production delivery rejects non-HTTPS URLs, embedded credentials, localhost, private-network hosts, and local or internal hostnames.
Fingerprint, not complete body
LeadProof temporarily processes the delivery body, then retains operational metadata and SHA-256 fingerprints rather than intentionally storing the complete production payload.
The recovery request must match
A final failure can be replayed only with the original idempotency key, matching payload and destination fingerprints, and an explicit replay header.
Signed fulfillment events
Stripe fulfillment verifies the raw payload with the webhook signing secret, an HMAC-SHA-256 signature, and a five-minute timestamp tolerance before processing.
Inactive access is suspended
Only active or trialing subscriptions receive production access. Canceled, unpaid, paused, incomplete, or otherwise inactive states disable the associated key.
Production data boundary
Stored for operations. Excluded by design.
- Source and destination hostname
- Status, attempts, response code, and latency
- Email domain and receipt identifier
- Payload and destination SHA-256 fingerprints
- Key prefix, plan, usage, and billing status
- Complete production lead payload
- Complete production API key
- Stripe payment-card number
- Destination credentials embedded in a URL
- Customer records as public product evidence
Verifiable request path
One constrained route from source to receipt.
LeadProof validates access and destination boundaries before attempting delivery, then returns a receipt with the final state and payload fingerprint.
1 Bearer key → SHA-256 lookup
2 Public HTTPS destination validation
3 Stable Idempotency-Key claim
4 Bounded delivery attempts
5 Destination response verification
6 Metadata-only receipt historySecurity questions
Clear answers and clear limitations.
Does LeadProof store complete production lead payloads?
Not intentionally. It processes the request for normalization and delivery, then stores operational metadata including source, destination hostname, status, attempts, latency, email domain, receipt ID, and SHA-256 fingerprints.
Can LeadProof reach a private network destination?
No. The production endpoint requires public HTTPS and rejects embedded credentials, localhost, private IPv4 ranges, loopback, private or link-local IPv6, and local or internal hostnames.
Is this page a security certification?
No. It is a first-party description of publicly inspectable controls and limitations, not an independent audit, penetration test, SOC 2 report, or guarantee of uninterrupted operation.
Test the production boundary on 25 live deliveries.
Use a verified account, one-time trial key, and your own authorized public HTTPS destination. No card required.