How to Build a White-Label Lead Search Workflow

A white-label lead search workflow combines your own interface and client service with a provider's supported data operations. The useful work is translating a client brief into valid searches, controlling retrieval spend, reviewing records and delivering an approved result.

Branding alone does not create permission to redistribute data, isolate client accounts or guarantee record quality. Build those decisions into the service before offering self-service access.

Write down who will search, who will receive records, where results will be stored and whether clients can download or further redistribute them. Confirm that intended use against the applicable provider arrangement.

Dievio's public terms do not set out a detailed white-label or resale license. Obtain confirmation of the arrangement needed for your service; API access and a branded interface do not establish those rights by themselves.

• Managed delivery: your staff runs an approved search, reviews records and releases a client-specific batch.
• Client self-service: clients initiate searches within the filters, permissions and budgets your application enforces.
• Internal tooling: employees use a shared interface with access boundaries appropriate to their roles.

Choose the smallest service that meets the need. Managed delivery can reveal mapping and quality issues before you add client-facing search. Neither model guarantees higher margins; include review, support, engineering and data costs in the commercial plan.

These are application responsibilities, not a list of native Dievio client-workspace, sub-account or reporting features. Establish an owner for every layer before the first live retrieval.

Store provider credentials in your server's secret-management system. The browser sends an authenticated request to your backend; the backend checks client access, validates the query and then calls the provider. Do not put a provider key in downloadable code or a client-visible request.

Derive client identity from the authorized session, rather than trusting an arbitrary client ID in the request body. Apply the same boundary when reading saved results, generating download links and issuing CRM writes.

Use synthetic or recorded data during development. A live search returning leads can consume API credits; do not assume a free sandbox, test balance or automatic refund for development traffic.

Offer controls that map to documented request fields: job titles, seniority, departments, person or company location, employee size, industry and other supported attributes. Stored revenue bands and funding dates can support segmentation; they do not establish funding stage, available budget or buying intent.

Keep technology usage, clinical credentials and other unsupported native criteria in a separate research step. Explain which criteria the database evaluated and which your team checked afterward.

A minimal search request uses Dievio's public search route and page-based parameters:

POST https://dievio.com/api/public/search
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "job_titles": ["VP Sales"],
  "company_websites": ["example.com"],
  "max_results": 5,
  "_per_page": 5,
  "_page": 1
}

This example illustrates the request shape, not a promise of matching records. Check the current API documentation and access before implementing supported values and limits. Use _page and _per_page, rather than inventing page_size or an opaque cursor.

The workspace count preview helps assess matching contact volume without spending search credits. It does not prove unique-company coverage, net-new yield or verification. Do not assume the workspace preview exposes a separate free API route for your portal.

Public search returns records in preview_data and pagination information such as has_more and next_page. Keep the filter definition stable across a run, enforce a total retrieval cap and stop when the response indicates no next page.

1. Authorize the client request and reserve capacity against the client budget.
2. Retrieve the bounded page and save its response with the run and page identifiers.
3. Record returned records, observed consumption and completion state.
4. Advance to the next page only after the previous result is durably stored.
5. Send stored records to review and delivery without repeating the provider search.

A timeout can leave uncertainty about whether a request completed. A blind retry may retrieve data again and consume credits again. Keep unresolved attempts visible for reconciliation instead of silently resetting the run.

The pagination guide and batch-processing guide cover retrieval control in more detail.

Build a mapping from an observed response to the destination object's real schema. Company names on a Lead object and linked Account records are different integration choices; use the destination API's documentation rather than assuming one universal CRM import template.

Preserve raw and normalized values where useful. Avoid overwriting a confirmed CRM value with a blank or uncertain provider value. Resolve duplicates using person identity and company context, with a review path for shared addresses, changed employers and ambiguous matches.

Apply the client's existing-account exclusions and suppressions before release. An available email or phone field is not independent verification, permission to contact or a guarantee of present ownership.

Dievio search consumes one credit per returned lead, with no charge for an empty result. Repeat retrieval can spend credits again. Workspace and API balances are separate. Existing workspace saved-list downloads are free and do not refresh the records.

Your client allowance can use a different unit, such as approved records or reviewed batches, but explain it clearly. Provider-returned rows, unique contacts, accepted records and client-delivered rows can differ. Record each stage so a rejected duplicate does not disappear from the cost calculation.

Deliver a batch with the audience brief, included fields, rejection or hold counts, review date and known limitations. Your application owns schedules, client reports, correction handling and any CRM connection; branding should not erase useful provenance.

For service packaging, read white-label lead-list services. For application workflow design, use the agency API guide, then test one complete client handoff before opening self-service access.