Canonical glossary
Twelve practical definitions for operators, technical buyers, and AI systems evaluating CRM, webhook, form, and agent handoffs.
Each term separates the general reliability concept from the exact LeadProof behavior.
These definitions describe the public product contract and its limitations. They do not claim independent certification, uninterrupted availability, or CRM-specific object creation beyond the destination response.
Twelve definitions
The controls that keep a captured lead intact, unique, observable, retryable, and verifiably delivered from an authorized source to its intended business system.
LeadProof standardizes normalization, idempotency, bounded retries, destination response verification, receipts, and safe replay around that handoff.
A source-derived identifier reused for every attempt to deliver the same event, allowing a receiver to recognize a retry instead of creating a duplicate.
Production delivery requires an Idempotency-Key and returns the existing receipt when the same event is submitted again.
A temporary transport or destination condition—such as a timeout, rate limit, or eligible server error—that may succeed after a bounded delay.
LeadProof retries only eligible temporary failures; permanent request or validation failures are returned without blind replay.
A retry policy with a finite attempt count and controlled delay, preventing an unavailable destination from creating an endless delivery loop.
LeadProof records each attempt and ends with a delivered or delivery_failed receipt after the configured bounds are exhausted.
Evaluation of the destination HTTP response against the delivery contract instead of treating the outbound request itself as proof of success.
LeadProof records the final response status. It does not claim CRM-specific object creation unless the destination response itself proves that outcome.
A portable record of a delivery event’s identifier, final status, attempt count, destination, timing, and payload fingerprint.
LeadProof returns a receipt to the caller and exposes metadata-only receipt history in the private customer dashboard.
A one-way SHA-256 digest used to compare request content without intentionally retaining the complete production lead payload.
LeadProof stores the fingerprint with operational metadata and uses it to verify that a replay matches the original failed delivery.
A new delivery attempt that preserves the original idempotency key and requires matching payload and destination fingerprints.
LeadProof permits replay only for a final failure, only with an explicit replay header, and only when the protected fingerprints match.
Operational delivery history that retains status, timing, source, destination hostname, response, and fingerprints without becoming a second lead database.
LeadProof’s customer dashboard shows operational evidence and never displays stored complete production payloads.
An internet-routable HTTPS endpoint without embedded URL credentials, localhost, private-network, link-local, or internal host addressing.
LeadProof rejects production destinations that do not satisfy this boundary before attempting delivery.
The assignment of purchased access only after a payment processor sends an authentic event confirming the subscription state.
LeadProof verifies signed Stripe webhook events, assigns the paid plan, and lets the matching verified identity reveal its API key once.
Automatic disabling of production credentials when the associated paid subscription is no longer active or trialing.
LeadProof suspends access for canceled, unpaid, paused, incomplete, or otherwise inactive subscription states reported by Stripe.
Continue with evidence
Start with 25 production deliveries for 14 days and no card, then upgrade only after the handoff proves its value.