B2B Leads API Debugging: Logs, Payloads and Field Mapping

Debug a lead API integration by finding the first boundary where the observed result differs from the intended one. A successful HTTP response, a useful record and a completed CRM update are three separate outcomes.

Capture a small reproducible case before changing filters, credentials or retry settings. This workflow is for troubleshooting an existing integration; use the testing guide when building fixtures and initial contract checks.

Record the endpoint, method, audience, page state and expected destination action. State the failure in observable terms: rejected credential, empty result array, unexpected field, repeated record or missing destination write.

A description such as “enrichment is broken” hides several possibilities. The request may be using an unsupported input, the source may have no available field, or a CRM mapping may have discarded the value.

• What input does the documented operation accept?
• What exact response or outcome was expected?
• What actually happened, and at which stage?
• When did the behavior first change?

For Dievio public search, confirm POST https://dievio.com/api/public/search, a JSON body and the bearer API key held on the backend. Verify the deployed configuration without exposing its value.

Use supported filter names and value formats. Numeric pagination uses _page and _per_page; max_results bounds the job. Do not copy a generic cursor or enrichment example into this route and assume the server interprets it as intended.

The filter guide covers audience design. For a suspected field-name error, compare the actual serialized request with the current API documentation, not only the object shown in your code editor.

The public search record array is preview_data. Inspect it before transformation. A field that is absent in the source cannot be recovered by renaming a destination column.

Use the error reference for current public-search failures. Do not require an invented nested error code or request identifier in order to log a useful diagnosis.

1. Start from the saved failing request definition.
2. Use a fixture to reproduce parser, mapping or validation failures without another retrieval.
3. When a live contract test is needed, choose a small explicit result cap.
4. Change one request variable at a time and record the result.
5. Retain both the original observation and the reduced case.

Compare the saved source value, transformed internal value and destination payload. Check type conversion, empty-string handling, null overwrite rules and field ownership. A normalization rule can silently erase a usable value if it assumes a format the source does not guarantee.

Keep identity review conservative. A similar name and company do not always identify the same person. The normalization workflow and field-mapping guide address those stages separately.

Capture the destination's documented response and check whether it represents completed work or queued processing. Verify the target record under the expected matching rule instead of assuming an accepted request created the intended field update.

If retrieval succeeded and was stored, debug the destination from that saved response. Repeating the source search can add cost and change the evidence without fixing the original mapping error.

Record the cause, affected jobs, correction and the case that now verifies the intended behavior. Include safe attempt references and timestamps for escalation, with credentials and unnecessary contact details removed.

Then check the recovery path: queued jobs, unresolved records and previously repeated writes may still need reconciliation. A corrected code path does not by itself repair every earlier delivery.