The short answer
A usable payload carries the full contact record, the qualification answers as structured values rather than free text, the attribution data, the consent record reference, and the merchant’s own submission timestamp. The last one matters most: without it you cannot measure your own time to first dial, which means you cannot tell a slow vendor from a slow floor.
Every vendor will describe their data as complete. A sample payload settles it in thirty seconds, and asking for one before signing is the cheapest diligence available.
| Field group | What it should contain |
|---|---|
| Contact | Full name, business name, phone, email, address |
| Qualification | Revenue band, amount requested, time in business, statements available |
| Verification | Whether the phone was code-verified, and when |
| Attribution | Source, campaign, and any ad identifier |
| Consent | A reference the vendor can resolve to the full record |
| Timing | The merchant’s submission timestamp, not the delivery time |
Structured values, not free text
A revenue field containing "about 90k give or take" is not a field you can route, score or report on. Bands and enumerated values are what let a CRM sort leads automatically, and a vendor whose payload is mostly free text is passing their data-cleaning problem to you.
Mapping it properly
- Send the vendor your field keys or a sample of the JSON your CRM expects, and have them shape their POST to it.
- Insist on a test lead before anything real, and check it landed in the right fields rather than in a notes blob.
- Confirm retries on failure, so an outage on your side does not silently drop records you paid for.
- Store the raw payload alongside the parsed record. It is the only way to debug a mapping problem after the fact.
That last habit costs nothing and saves an afternoon the first time a field silently stops populating after a vendor changes something upstream.