adsoraGet the source-specific posting instructions
Use the submission document for the buyer account and campaign you are connecting. A general example from a help center may explain the sequence, but it cannot tell you your account’s required fields, accepted values or configured response. Ask who owns the document and how the seller will learn about changes.
Do not assume that every ping excludes contact details. ActiveProspect’s documented LeadConduit real-time bidding flow calls for the complete lead data needed to evaluate its rules. Other systems describe a partial-data ping followed by a fuller post. Use the actual specification and approved data-sharing requirements for this connection.
Sources: ActiveProspect: real-time bidding.
Write a mapping sheet with allowed values
| Field concept | What both teams must agree |
|---|---|
| Project type | Exact accepted values for replacement, repair and other work |
| ZIP code | String format that preserves leading zeroes; service-location meaning |
| Property relationship | How owner, tenant, manager and unknown are represented |
| Project size | Unit of measurement and treatment of an unanswered question |
| Capture time | Timestamp format, timezone and original capture event |
| Lead and transaction IDs | Which IDs remain stable across ping, post and retry |
| Capture evidence | Required reference, its meaning and who checks the result |
Keep unknown separate from no. A source that did not ask whether the homeowner wants financing should not send a value that implies the homeowner declined it. Treat an unanswered project-size question the same way. Agree whether an unknown value is allowed, causes a reject or requires a different program.
Use a sample record to expose ambiguous fields
The following is an illustrative mapping fixture, not a working request to Adsora or a platform API. It deliberately excludes credentials and contact details. Replace its names and values with the fields in your receiving specification; do not post this object to a live buyer.
In this example, window_count describes the requested project size and project_type uses a controlled value. Confirm whether the source collected the count from the homeowner, inferred it or left it unknown. Your acceptance rules should reflect that distinction.
{
"source_lead_id": "synthetic-test-001",
"project_type": "window_replacement",
"service_zip": "01234",
"window_count": 8,
"captured_at": "2026-09-19T17:00:00Z"
}Map the response as carefully as the request
Document the buyer’s accepted, rejected and error outcomes. Keep HTTP transport status separate from the business outcome in the response body. A server can return a readable response that says the lead was rejected. Record the reason and transaction reference your seller needs to reconcile it.
Confirm whether a successful ping returns a reference that must be included in the post. Define bid currency, price precision and validity rules where the program uses bidding. A renamed field can break response parsing without changing the apparent success of the network request. Test the exact body your system will read.
Test values at the edge of the buying rules
Run synthetic tests for an approved project, an excluded repair, an unknown project type, a leading-zero ZIP, a missing required value and a repeated source ID. Check the response and the downstream CRM record. Include one record that crosses a date or timezone boundary if delivery hours depend on it.
Save the approved mapping, example responses and test results with a version date. When either team changes a required value, rerun the affected cases before traffic resumes. Share private posting instructions through the agreed onboarding channel, never through a public website form.