adsoraA CSV checklist for recording expected responses, purchase counts, CRM records and the owner of each exception.
Download the ping/post test matrix ↓Start with the specification for this connection
Ask both parties to identify the approved specification and its version or date. Copy the endpoint, authentication method, required fields, allowed values and response definitions into a controlled launch document. Put secrets in the agreed credential system, not in that document.
Provider examples are not interchangeable. PX documents a transaction ID connecting ping and post; Lead Prosper generates supplier specifications from the configured campaign. Those are reasons to use the actual account instructions instead of adapting an unrelated payload found in a blog.
Agree on synthetic test records and a test destination. Keep test inquiries out of live contact queues and supplier billing. If either party cannot isolate test traffic, settle a supervised testing process before sending records.
Sources: PX posting instructions; Lead Prosper campaign specifications and testing.
Record the expected result before running the test
| Case | What to inspect |
|---|---|
| Eligible inquiry and valid post | Purchase response, source ID and correct CRM owner |
| Unapproved ZIP or project | Decline reason and absence of a billable purchase |
| Missing required field | Parser behavior and a usable error response |
| Expired or unknown bid reference | Defined rejection or recovery behavior |
| Repeated post for the same purchase | No unintended second purchase or CRM opportunity |
| Timeout after the receiver processes a post | An uncertain state and an agreed reconciliation route |
| Cap reached or branch paused | Effective timing and handling of in-flight offers |
| CRM unavailable after purchase acceptance | Durable recovery record, notification and retry ownership |
| Two concurrent posts near a cap | Counting and reservation behavior under simultaneous delivery |
Expected behavior comes from the parties' specification. Do not assume every platform reserves capacity at ping, uses the same timeout or returns the same rejection code. Write those decisions into the matrix before marking a test passed.
Add a source-specific case whenever the contract introduces a rule. A window-count minimum, an excluded property type and a ZIP with a leading zero each deserve a sample. Keep each test focused enough that a failure can be traced to one condition.
Trace the test with a shared ID
Keep the sent record, received response, purchase entry and CRM result together. Record timestamps with timezones. If a test ends in an uncertain response, the receiving party should be able to search for the purchase without requiring another potentially billable post.
The example below is an internal QA record you can adapt. It is not an Adsora endpoint, a provider payload or a claim that any platform accepts these field names.
{
"test_case": "POST_RETRY_AFTER_TIMEOUT",
"synthetic_record_id": "QA-RETRY-001",
"expected": {
"billable_purchases": 1,
"crm_opportunities": 1
},
"actual": {
"billable_purchases": null,
"crm_opportunities": null
},
"status": "not_run",
"owner": "assigned before launch"
}Repeat the affected cases after a change
A test result applies to the configuration that produced it. Record the campaign version and receiving rule set. If a supplier changes an allowed project value or the buyer changes its acceptance parser, rerun the cases that depend on that change.
Pay particular attention to a successful HTTP response carrying a failed business result. The supplier needs to parse the purchase decision inside the response where the specification requires it. Save both layers in the test evidence.
Ask the branch to confirm the fields its team sees. A technically accepted lead can still arrive with an empty project description or the wrong ownership assignment. Include a receiving-team check before signing off on the connection.
Define what must pass before live delivery
Require all purchase, duplicate and routing cases for the agreed scope to pass. Assign an owner to each remaining issue and decide whether it prevents launch. Keep the pause procedure available to the people monitoring the first live records.
Start with a controlled purchase limit and reconcile accepted source IDs against the receiving queue. A new record that cannot be traced is a delivery exception to investigate immediately. Bring the completed matrix and your specification to Adsora when discussing automated delivery.