B2B Leads API Testing: Mocks, Fixtures and Safe Live Checks

Test a B2B leads API integration in two layers: repeatable tests against your own synthetic fixtures, then a small live check against the provider’s documented endpoint. The first layer exercises mapping, pagination and failures without real contact data or provider charges. The second confirms authentication and the real response contract.

For Dievio, the documented lead-search endpoint is POST https://dievio.com/api/public/search. It uses a bearer API key and a separate API credit balance. This guide does not rely on a dedicated Dievio sandbox host or free sandbox keys. A live request that returns leads consumes API credits, even when you intend it as a test.

Keep your CRM mapping and business rules behind a small client interface. In local tests, return a fixture from that interface. In production, call the actual API. This gives you control over responses and prevents test cases from accidentally sending large paid searches.

Use invented names and reserved example domains in fixtures. Include complete records, missing emails, missing phone numbers, duplicate profile URLs, non-ASCII names and companies with similar names. None of those fixtures should be presented as real provider data or an exact current response schema.

// Illustrative local fixture: adapt fields to a saved real response.
const fixture = {
  success: true,
  preview_data: [
    { full_name: 'Example Person', work_email: null,
      job_title: 'Operations Director', company: 'Example Company' }
  ],
  page: 1,
  has_more: false,
  next_page: null
};

Store a redacted, approved real response separately when you need a contract fixture. Remove personal details and credentials before sharing it. Record the observation date and the specific fields your integration depends on.

These are integration test cases, not a claim that every provider returns identical errors. Dievio’s public search route documents missing-key and balance failures through its implementation; inspect the actual response body during a live check. If an intermediary returns 429, respect its retry guidance and keep retries bounded rather than inventing a universal rate limit.

Dievio search accepts _page, _per_page and max_results, and returns pagination fields including has_more and next_page. Test multiple pages in fixtures. Assert that your client stops at the total limit and does not restart from page one after a downstream CRM error.

A search that succeeded upstream can still fail before your system records its response. Treat that timeout as an uncertain outcome. Replaying the search may return records and spend credits again. Save completed responses before delivery, checkpoint each stage and retry destination writes from stored results where possible. Deduplicating CRM writes does not make repeated provider calls free.

Create or select an API key in your account and keep it on your server. Confirm your separate API balance. Use a small audience and explicit limits, then inspect the full response before building a larger job. Never put a real key in article code, browser-side JavaScript or a shared screenshot.

curl -X POST https://dievio.com/api/public/search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "job_titles": ["Founder"],
    "person_location_country": ["United States"],
    "max_results": 5,
    "_per_page": 5,
    "_page": 1
  }'

The example may return up to five records and consume up to five API credits. It is a real search shape, not a mock or free sandbox call. Check the current public API page and dashboard documentation before running it, because request contracts and commercial terms can change.

Import the test response into your own staging CRM or test database. Confirm field mapping, encoding, record ownership, duplicate policy and suppression behavior. Use the contact field mapping guide to document required versus optional values.

If your workflow delivers webhooks, test your own receiver with synthetic payloads. Confirm signature handling where implemented, request retries, duplicate events and a dead-letter path. Do not describe that receiver as native Dievio webhook delivery unless your provider documentation explicitly supplies that feature.

Before expanding the result cap, record the endpoint, field mapping, stop conditions, balance check, retry ceiling and owner of failed jobs. Compare the first live response with your fixture and update the contract test when a legitimate schema change occurs.

Monitor returned records, accepted records, credit use, failure reasons and duplicate destination writes. Keep technical logs free of API keys and unnecessary personal data. The batch processing guide covers a larger delivery workflow, while API debugging helps isolate a failing stage before you scale it.