Receiving a request on a leads marketplace is not just a matter of a name and a phone number turning up in an inbox. Between the moment the platform validates a request and the moment a receiving company can work it in its own tools, there is a decisive technical layer: delivery. It sets which channel the request arrives through — e-mail, dashboard, webhook, export or CRM connector —, how fast, in what format, and with what proof of transmission. leads-qualifie.ch treats this layer as a full-fledged link in the marketplace, held to the same traceability requirements as capture and scoring.
This dossier describes the integration and delivery mechanisms independent of any single category: the different channels through which a request can be handed to a company, how real-time webhook delivery works, continuous synchronisation with a customer relationship management tool, the timestamped traceability of every delivery, and how the platform handles receipts, duplicates and delivery failures. The aim is to show that delivery is not a peripheral technical detail, but a structuring component of trust between the two sides of the market.
The delivery channels for a request
A single validated request can be handed to the receiving company through several channels, chosen according to its intake profile and technical maturity. The most immediate is an e-mail notification, paired with a display in the platform dashboard: the company sees the request appear, with its contact details, category, zone and score, without having to set up any tool at all. This channel suits a tradesperson or a small structure that handles requests by hand, one at a time, with no dedicated system to feed. At the other end of the spectrum, a structured company with technical resources will favour automated delivery by webhook or by connection to its business software, so that each request feeds straight into its handling chain with no re-keying.
The essential point is that the delivery channel is decoupled from the content: the request transmitted is exactly the same — same data, same validation, same score — whatever route is chosen to carry it. A serious marketplace does not reserve the best-quality requests for a particular channel, nor degrade the format depending on the means of receipt; it offers several doors into an identical flow, so that no company is excluded for lack of a tool, nor favoured by its technical capacity alone. Choosing a channel is therefore a matter of each company's handling ergonomics, not a commercial sorting carried out by the operator.
Real-time delivery by webhook
The webhook is the fastest delivery channel a marketplace can offer. Technically, it is an HTTP call the platform sends to an address (a URL) configured by the receiving company, at the exact moment a request is assigned to it. Unlike periodic polling, where the company would query the platform at regular intervals, the webhook works by push: it is the platform that takes the initiative to transmit the request as soon as it is ready, with no waiting latency. The message sent carries a structured payload — most often in JSON format — bundling the category, the geographic zone, the customer's contact details, the proof of consent, the assigned score, the timestamp and a unique identifier specific to the request.
This immediacy has a direct effect on handling: the company's system receives the request, automatically creates a record, and can trigger a callback within minutes of capture, while the customer's purchase intent is still fresh. To guarantee the message's origin, the platform generally signs each send with a shared secret key, which the company checks on receipt: this prevents a third party from injecting false requests into its system. The webhook is therefore aimed first at demand-side companies that have a developer or a tool able to listen for and process these calls, and that want to make the most of a request's freshness.
Export and continuous synchronisation with a CRM
Not every company needs — or has the means for — a webhook integration. For them, delivery goes through export and synchronisation with their customer relationship management tool. Export takes the form of a structured file, typically CSV, retrievable manually or on a schedule, which the company imports into its CRM at a chosen interval. Synchronisation, more advanced, relies on a connector that drops each request straight into the CRM as it arrives, matching the platform's fields to the software's fields — the category becomes a pipeline stage, the zone a segmentation criterion, the unique identifier a reconciliation reference.
Two requirements guide this synchronisation. The first is deduplication on import: the unique identifier attached to each request lets the CRM recognise a record already present and avoid the same request creating two separate entries. The second is preserving the traceability metadata: a well-designed export carries not just the customer's contact details, but also the source that produced the request, the timestamp of its capture, its score and its consent status. The company thus finds, inside its own tool, the full provenance chain of each request — the condition for it to be able, in the event of a dispute, to trace back to the origin without depending solely on the platform.
The timestamped traceability of every delivery
On a two-sided marketplace, delivery is not a one-off act forgotten once the request has gone: every delivery is logged. The platform keeps the timestamp of each step — capture by the source, validation, assignment to one or more companies, delivery attempt, receipt confirmation — so that for each request there is a continuous trace, on the supply side as much as the demand side. This register is the backbone of trust on a market where the two parties do not know each other directly: it anchors the source and the receiving company to a single record that neither can rewrite after the fact.
This timestamped traceability plays a double role. First, it is the instrument for resolving disputes: when a company contests a request — unreachable contact, duplicate, need outside its zone — the arbitration is made against the delivery log, not against anyone's recollection. Second, it feeds the scoring system: the intervals measured between capture, delivery and the company's first response nourish the ongoing assessment of sources as well as receiving companies. Finally, the timestamp ties directly into FADP requirements — knowing who received which data, when, and on what basis of consent is an integral part of the processing accountability the platform must be able to document.
Reliability, receipts and failure handling
A delivery is only worth anything if it is reliable, and a serious marketplace does not consider a request delivered until it has received confirmation. On the webhook channel, this confirmation takes the form of a receipt: the company's system returns a success code attesting that the request has arrived and been accepted. As long as this receipt is not received, the platform treats the delivery as pending and can re-send the call under a logic of spaced retries, to cover temporary unavailability of the destination address. Deduplication meanwhile guarantees that the same request is never counted or billed twice merely because of a technical re-send.
Failure handling takes on particular importance in a two-sided context, where a purely technical problem must penalise neither party. If a company's address stays unreachable after several attempts, the request is not lost: it falls back to a backup channel — e-mail notification, availability in the dashboard — and an alert is raised, without the source that produced the request being held responsible for a failure located on the receiving side. Conversely, a request that no recipient can receive is flagged for arbitration. The operator thus monitors delivery health — receipt rates, fallback rates, delays — as a full component of its quality-control function, on the same footing as auditing sources.