adsoraSeparate the clocks in the connection
A request timeout limits how long one system waits for a response. A ping-validity window governs how long a later post may use an earlier ping. A delivery-hours rule determines when the buyer is open. These settings can all affect the same lead, but changing one will not necessarily fix another.
Lead Prosper’s error documentation distinguishes a failed connection, an invalid ping ID and a post sent outside the allowed ping window. Treat those as separate investigation paths. Read the current campaign and platform requirements before choosing a timeout; a duration from another vendor’s integration is not a universal standard.
Sources: Lead Prosper: error messages.
Create an unknown state for an unanswered post
Suppose the buyer accepts a post and creates a transaction, then the response is lost. If the seller immediately posts again under a new ID, the buyer may create another transaction or reject the second request as a duplicate. Either result can leave the two systems reporting different counts.
Preserve the original source ID, request reference and send time. Use the buyer’s supported status lookup or reconciliation process to establish what happened. If the platform has no lookup, agree on an operational exception queue and a named owner. Do not silently turn an unanswered request into a confirmed rejection.
Agree on duplicate-safe retry behavior
HTTP POST is not inherently idempotent. The HTTP standard cautions against automatically retrying a non-idempotent request unless the client knows the operation is safe to repeat or knows the original was not applied. A lead-purchase integration therefore needs explicit behavior for repeats.
Ask whether the receiver supports an idempotency key or another stable transaction identifier. Define its scope, retention period and expected repeat response. A field called lead_id is not enough evidence that duplicate purchases are prevented. Test the same request twice and verify both the commercial transaction count and the CRM count.
Test recovery before an outage
| Test case | Evidence to inspect |
|---|---|
| Response delayed beyond sender deadline | Buyer status, seller unknown state and transaction reference |
| Same post retried with the same identity | One agreed purchase outcome and no extra CRM record |
| Post after the ping is no longer valid | Expected rejection and a recorded reason |
| Buyer temporarily unavailable | Bounded recovery behavior and an owner for unresolved records |
| Malformed response | Error visibility instead of a guessed acceptance |
Use a test receiver or the platform’s approved test mode. Never create outage tests by disrupting a live buyer endpoint. Keep retry limits and any delay schedule in the agreed configuration so a temporary failure cannot cause unlimited repeat traffic.
Close the exception before closing the invoice
Reconcile uncertain requests against final buyer transactions using stable IDs. Record whether each became accepted, rejected or remains unresolved. Preserve the history when correcting a result so finance can explain a change between yesterday’s report and the invoice.
Send the integration owner a compact incident record: source ID, campaign, request time, observed failure and the final buyer outcome when known. Keep credentials and homeowner data out of screenshots and public support threads. Use the incident to add one missing test or clarify one recovery rule.