Authorized Professional Directory Intelligence avatar

Authorized Professional Directory Intelligence

Pricing

from $2.55 / 1,000 authorized professional intelligence rows

Go to Apify Store
Authorized Professional Directory Intelligence

Authorized Professional Directory Intelligence

Turn buyer-authorized or licensed professional directory exports into privacy-aware evidence, freshness, confidence gaps, review priority, and safe next actions without scraping or network requests.

Pricing

from $2.55 / 1,000 authorized professional intelligence rows

Rating

0.0

(0)

Developer

Tim Zinin

Tim Zinin

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

1

Monthly active users

8 days ago

Last modified

Share

Normalize professional directory records that you own or are licensed to process into review-ready evidence, freshness, gaps, human actions, and exact pay-per-result reconciliation — without fetching Doctoralia or any other external source.

Built for: directory operators, clinics, professional associations, data stewards, compliance teams, and integration teams processing an authorized export under a documented purpose.

Commercial unit: one delivered authorized professional directory intelligence row. The automatic Actor start event is separate. Free diagnostics do not intentionally emit result-found.

Authorized Professional Directory Intelligence: authorized export to privacy-aware human review

What you get

This Actor turns a minimal, closed professional-directory record into a stable review artifact. It preserves the familiar name, specialty, city, rating, review-count, profile-URL, and processing-time fields used by older integrations while adding the evidence that a commercial workflow needs: source and rights labels, deterministic identity, freshness basis, confidence gaps, a review priority, a human action, settlement-neutral billing intent, and current-run terminal reconciliation.

  • Exactly one result candidate per valid, source-scoped professional ID after deterministic deduplication.
  • Zero source fetching: no browser, search page, API, DNS lookup, redirect, or recorded URL request.
  • A closed input that rejects unknown fields such as phone, email, biography, notes, review text, or patient data.
  • Explicit buyer authorization and source-context fields instead of pretending that public visibility grants reuse rights.
  • Freshness derived only from the optional buyer-supplied source timestamp, with the basis visible.
  • Confidence and gaps that describe evidence sufficiency, not professional skill, quality, reputation, availability, or suitability.
  • A deterministic stable ID and digests for reconciliation. They do not anonymize the underlying person.
  • A human-review action and safeToAutomate:false on every row.
  • Free migration and validation diagnostics that remain distinguishable from result candidates.
  • One KVS OUTPUT receipt bound to the current run, with paid/free/withheld/unknown partitions and replay truth.

Version 0.2 deliberately replaces the old live-directory search behavior. Existing Tasks can keep the technical Actor slug, but legacy items input no longer causes a Doctoralia request. It produces a free migration diagnostic telling the operator to provide an authorized export.

Who uses it

The product is useful when a team already has a documented right to process a directory export and needs consistent evidence and reconciliation before records enter a downstream system.

  • A professional association normalizing a member directory it operates.
  • A clinic group cleaning a directory of affiliated professionals under its own governance.
  • A licensed data provider preparing a bounded downstream delivery with a preserved licence statement.
  • A compliance team checking whether every record has provenance, freshness gaps, and a manual action.
  • A CRM integration team staging minimal records in quarantine before an authorized human review.
  • A data steward finding stale or incomplete source records without revisiting third-party pages.

It is not designed for scraping, contact harvesting, patient discovery, reputation ranking, automated outreach, credential verification, care decisions, eligibility decisions, employment screening, or building a people-data marketplace. Do not submit records merely because a page is publicly viewable. Public access and commercial downstream rights are different questions.

How to run

  1. Obtain an export under a licence, organizational authority, or professional consent that covers your intended processing and delivery.
  2. Remove contact details, biography, notes, review text, patient information, and any field outside the closed contract.
  3. Choose the truthful sourceContext and preserve a stable professionalId from that source.
  4. Write a concise sourceName and sourceLicense statement that a reviewer can trace to your documentation.
  5. Submit one to 100 records and the exact authorization sentence. Unknown record fields are rejected rather than silently retained.
  6. Inspect Dataset diagnostics before using result candidates. Diagnostics are part of the run truth, not noise to discard.
  7. Read KVS key OUTPUT and verify its run ID, counters, settlement state, terminal status, and replaySafe value.
  8. Route every accepted row to a human who can verify rights, identity, credentials, currentness, and intended purpose.

Example input:

{
"schemaVersion": "2.0",
"authorization": "I confirm I am authorized to process and deliver these professional records",
"sourceContext": "provider_licensed_export",
"professionals": [{
"professionalId": "professional-101",
"profileUrl": "https://directory.example.com/professional-101",
"name": "Dra. Ana Ejemplo",
"specialty": "Dentistry",
"city": "Ciudad de México",
"rating": 4.8,
"reviewCount": 42,
"sourceName": "Licensed provider directory export",
"sourceLicense": "Buyer confirms downstream processing and delivery rights",
"sourceRetrievedAt": "2026-08-12T10:00:00Z"
}]
}

The Actor processes records serially for exact settlement. maxConcurrency remains accepted only so an old Task does not fail schema parsing; it has no effect because version 0.2 performs no source calls.

Authorized Professional Directory Intelligence: authorize, normalize, assess, and reconcile workflow

Pricing

The Actor uses pay per event. A run may incur the automatic apify-actor-start event. Each valid result candidate is linked to result-found only when pushed to the Dataset. The named counter must advance by exactly +1 for paid settlement. Dataset rows themselves describe billing intent; the current-run KVS OUTPUT is the settlement authority.

TierStart eventOne delivered result row
FREE$0.00500$0.00300
BRONZE$0.00475$0.00285
SILVER$0.00450$0.00270
GOLD$0.00425$0.00255
PLATINUM$0.00410$0.00246
DIAMOND$0.00400$0.00240

At FREE-tier rates, one paid row plus start is $0.008; ten paid rows plus start are $0.035. At DIAMOND rates, one paid row plus start is $0.0064; ten paid rows plus start are $0.028. These examples exclude platform compute, storage, and any separate downstream service. Always read the live pricing panel for the account tier in effect.

Invalid input fails before a Dataset result. Legacy migration and rejected-record diagnostics do not intentionally emit result-found, although the separate start event can still apply. If a linked push returns but the platform proves the charge limit prevented the named event, the row is delivered free and OUTPUT says so. If delivery or settlement is unknown, the Actor stops and forbids blind retry.

Input contract

The public version is 2.0. It is intentionally narrow:

InputRequiredContract
schemaVersionNoIf present, exactly 2.0.
authorizationYes for result candidatesExact confirmation: I confirm I am authorized to process and deliver these professional records.
sourceContextNoOne of provider-licensed export, organization-owned directory, professional-consent export, or other authorized source.
professionalsYes for current behaviorOne to 100 closed objects.
itemsLegacy onlyAt most 25 strings; produces one free migration diagnostic and no request.
maxConcurrencyLegacy onlyAccepted from 1 to 20 and ignored.

Each professional object requires professionalId, profileUrl, name, specialty, sourceName, and sourceLicense. City, rating, review count, and source retrieval time are optional. The URL must be HTTPS without embedded credentials. Strings are trimmed and bounded. Ratings must be 0–5, review counts nonnegative safe integers, and timestamps real UTC calendar values.

Deduplication uses lowercase sourceName:professionalId. It does not merge people across sources and does not compare names. Invalid objects are counted and represented by a free diagnostic while valid siblings can still be processed. An all-invalid submitted array is a partial diagnostic run, not a paid success.

Happy, partial, and failure output

A happy run contains result candidates, one current-run OUTPUT, exact Dataset and named-event partitions, and no fatal error. Partial runs can include rejected records, migration diagnostics, a reached charge cap, a confirmed-free linked row, or an evidence gap. A failed run stops on input failure, pricing drift, run-identity failure, diagnostic-write failure, unknown delivery, unknown settlement, settlement anomaly, KVS failure, or exit failure.

Run-bound success example:

{
"runId": "doctoraliaRunA101",
"buildId": "CURRENT_IMMUTABLE_BUILD_ID",
"status": "SUCCEEDED",
"evidenceAccepted": true,
"output": {
"schemaVersion": "2.0.0",
"kind": "authorized_professional_directory_intelligence_output",
"status": "COMPLETE",
"runId": "doctoraliaRunA101",
"requestDigest": "sha256:REPLACED_BY_CURRENT_REQUEST_DIGEST",
"input": {"requestedCount": 1, "uniqueCount": 1, "duplicateCount": 0, "invalidCount": 0, "legacyInputCount": 0},
"run": {"attemptedCount": 1, "successfulCount": 1, "failedCount": 0, "deliveredRowCount": 1, "paidRowCount": 1, "freeRowCount": 0, "withheldRowCount": 0, "unknownDeliveryCount": 0, "unknownSettlementCount": 0, "partial": false, "budgetStopped": false, "fatalError": null, "replaySafe": false, "safeToAutomate": false},
"delivery": {"eventName": "result-found", "attemptedPushCount": 1, "resultChargeCountBefore": 0, "resultChargeCountAfter": 1, "confirmedEventDelta": 1, "confirmedDatasetWrites": 1, "lastAttempt": {"stableId": "sha256:REPLACED_BY_ROW_STABLE_ID", "state": "confirmed_paid", "resultChargeCountBefore": 0, "resultChargeCountAfter": 1, "delta": 1, "aggregateChargedCount": 2, "eventChargeLimitReached": false}},
"errors": [],
"resultsUrl": "https://api.apify.com/v2/datasets/CURRENT_DATASET_ID/items",
"startedAt": "2026-08-13T00:00:00.000Z",
"completedAt": "2026-08-13T00:00:01.000Z",
"terminal": {"outcome": "COMPLETE", "failureStage": null, "primaryKvsWrite": "confirmed", "recoveryKvsWrite": "not_attempted", "exit": "requested"}
}
}

Run-bound legacy migration example:

{
"runId": "doctoraliaRunLegacy101",
"buildId": "CURRENT_IMMUTABLE_BUILD_ID",
"status": "SUCCEEDED",
"evidenceAccepted": true,
"output": {
"schemaVersion": "2.0.0",
"kind": "authorized_professional_directory_intelligence_output",
"status": "PARTIAL",
"runId": "doctoraliaRunLegacy101",
"requestDigest": "sha256:REPLACED_BY_CURRENT_REQUEST_DIGEST",
"input": {"requestedCount": 0, "uniqueCount": 0, "duplicateCount": 0, "invalidCount": 0, "legacyInputCount": 1},
"run": {"attemptedCount": 0, "successfulCount": 0, "failedCount": 0, "deliveredRowCount": 1, "paidRowCount": 0, "freeRowCount": 1, "withheldRowCount": 0, "unknownDeliveryCount": 0, "unknownSettlementCount": 0, "partial": true, "budgetStopped": false, "fatalError": null, "replaySafe": true, "safeToAutomate": false},
"delivery": {"eventName": "result-found", "attemptedPushCount": 0, "resultChargeCountBefore": 0, "resultChargeCountAfter": 0, "confirmedEventDelta": 0, "confirmedDatasetWrites": 1, "lastAttempt": null},
"errors": [],
"resultsUrl": "https://api.apify.com/v2/datasets/CURRENT_DATASET_ID/items",
"startedAt": "2026-08-13T00:00:00.000Z",
"completedAt": "2026-08-13T00:00:01.000Z",
"terminal": {"outcome": "PARTIAL", "failureStage": null, "primaryKvsWrite": "confirmed", "recoveryKvsWrite": "not_attempted", "exit": "requested"}
}
}

The examples show the lattice, not reusable IDs or digests. A consumer must bind every decision to the actual platform run ID and actual OUTPUT. Never construct a success from a Dataset row alone.

Field dictionary

FieldMeaning and boundary
schemaVersion2.0.0 for delivered rows. The public input contract is 2.0.
recordTypeauthorized_professional_directory_intelligence for a result candidate; professional_directory_processing_diagnostic for a free migration or validation diagnostic.
stableIdSHA-256 over the supplied source name and professional ID. It supports deterministic joins; it is not anonymization.
professionalIdThe buyer-supplied stable identifier from the authorized export.
inputLegacy compatibility field. It is null in the replacement contract because the Actor no longer searches a directory.
foundTrue for a valid result candidate and false for a free diagnostic. It is not a credential or availability assertion.
nameProfessional name supplied by the buyer-authorized source.
specialtySupplied directory specialty. It is not independently checked against a licensing authority.
rating / reviewCountOptional aggregate values supplied by the authorized export. Review text is not accepted.
cityOptional supplied locality. It may be absent without invalidating the record.
profileUrlRecorded HTTPS reference. The Actor never opens, follows, or verifies the URL.
scrapedAtLegacy-compatible alias of observedAt. Nothing was scraped by version 0.2.
observedAtUTC time when this Actor normalized the submitted record.
freshnessBuyer-timestamp-based fresh, aging, stale, or unknown assessment with age and basis.
changeAlways not_measured because one submitted snapshot cannot establish a change history.
confidenceEvidence sufficiency for the closed record shape, with explicit gaps. It is not professional-quality confidence.
evidenceDigests of the submitted professional record and rights statement. Digests prove byte binding, not source truth.
recommendedActionHuman step: verify rights, identity, credentials, current profile, and the intended lawful purpose.
priorityReview ordering derived from supplied timestamp and city coverage: HIGH, MEDIUM, or LOW.
safeToAutomateAlways false. The Actor does not authorize outreach, ranking, care, hiring, or credential decisions.
summaryCompact review sentence built only from accepted fields.
failureDiagnosticsNull for result candidates; a typed free diagnostic for migration or rejected records.
billingSettlement-neutral intent. Actual paid/free/anomalous/unknown settlement lives only in current-run KVS OUTPUT.
sourceName / sourceLicenseBuyer-supplied source label and rights statement. The Actor validates shape, not legal sufficiency.
sourceRetrievedAtOptional buyer-supplied UTC observation time used for freshness.
requestDigest / inputDigestStable bindings to the normalized request and record.

The default Dataset overview surfaces the review fields first. Full raw records preserve every contract field for API consumers. Store display formats use JSON for nested evidence, confidence, freshness, and billing so a consumer does not mistake an object for plain prose.

Evidence and boundaries

There are three different claims in this product, and they must not be collapsed:

  1. Shape claim: the submitted record passed the closed normalization contract.
  2. Buyer-attestation claim: the buyer supplied a source and rights statement plus the exact authorization sentence.
  3. External-truth claim: not made. The Actor did not fetch or verify the source, person, licence, credential, rating, availability, or intended purpose.

Confidence describes the first two layers only. Freshness uses the supplied retrieval timestamp only. A source digest proves that the same submitted string is referenced later; it does not prove that the statement is legally sufficient. A stable ID proves deterministic construction; it does not prove a unique real-world identity. A recorded HTTPS URL proves only that a string passed syntactic validation.

Material gaps remain visible: missing city, missing retrieval time, missing rating aggregates, buyer-supplied data not independently verified, credentials not checked, and directory display not proving availability or suitability. The product intentionally refuses to turn these gaps into a hidden score.

Privacy boundaries are equally important. Names, professional affiliations, specialty, locality, ratings, URLs, and stable identifiers may relate to identifiable people. Maintain a lawful and documented purpose, minimize fields, restrict access, set retention and deletion periods, support correction and objection, and prevent repurposing for harassment, discrimination, sensitive inference, or unsolicited outreach. Consult qualified counsel for the relevant jurisdiction and use case.

Decision routing

Every result candidate is review-required and safeToAutomate:false.

StateRouteDo not do
HIGHReview source rights, identity, credentials, current profile, and intended purpose promptly.Do not auto-contact or auto-approve.
MEDIUMResolve missing timestamp/locality or other evidence gaps before downstream use.Do not treat incomplete context as a negative professional signal.
LOWRefresh or correct stale/weak source evidence first.Do not infer professional quality from stale metadata.
Free diagnosticCorrect the contract or migrate the legacy Task.Do not bill or treat it as a professional result.
Unknown delivery/settlementStop and reconcile platform Dataset, KVS, and counters manually.Never blind-retry.
Fatal pre-delivery failureCorrect the explicit error and intentionally start a new run if replaySafe is true.Do not assume the prior start event is reversible.

Priority is workflow ordering, not a lead score. Rating and reviewCount never affect an autonomous decision. A downstream system may automatically store, checksum, or route the record under its own controls, but it must not automatically make a business or people decision from this output.

Commercial playbooks

1. Licensed provider-directory migration

Export only contract-approved fields, preserve the provider record ID, state the licence basis, run a small sample, inspect diagnostics and OUTPUT, then scale only after legal and privacy review.

2. Organization-owned directory cleanup

Submit records maintained by your organization, route LOW-priority or stale rows to data stewardship, and use stableId to merge corrections without treating it as an identity authority.

Use consent records outside this Actor, submit only the minimal directory fields, keep a withdrawal route, and delete downstream copies when the lawful basis expires.

4. CRM enrichment staging

Write Dataset rows to a quarantine table, require a reviewer to confirm identity and intended purpose, then map approved fields. Never auto-enroll rows into sales sequences.

5. Credential-review queue

Use the output only to prioritize manual checks against the appropriate official regulator. Do not infer that a supplied profile or rating proves current licensure.

6. Directory freshness audit

Supply sourceRetrievedAt, sort by freshness status, and re-export stale source records under the same authorized process. The Actor itself never revisits URLs.

7. Duplicate consolidation

Deduplication is scoped to case-insensitive sourceName plus professionalId. Investigate cross-source duplicates manually because similar names do not prove the same person.

8. Privacy-minimized analytics

Aggregate counts downstream and restrict row access. Hashes remain linkable and should be handled as personal-data-adjacent identifiers where applicable.

9. Marketplace or partner handoff

Pass along the source rights statement, output contract version, current-run OUTPUT, and retention instructions. Do not imply that the Actor grants redistribution rights.

10. Legacy Task migration

A Task that still submits items receives a free diagnostic and no directory request. Replace it with professionals, sourceContext, and the exact authorization sentence.

11. Failed-run reconciliation

Read platform status and KVS OUTPUT. Retry only a pre-delivery failure marked replaySafe true; never blind-retry unknown delivery or settlement.

12. Controlled reprocessing

A new run is a new commercial attempt and may incur a new start and result charge. Compare requestDigest and stableId before deliberately reprocessing.

For every playbook, define an owner, purpose, source authority, review SLA, access policy, correction channel, retention date, downstream recipients, and a no-blind-retry runbook before processing production data. The Actor supplies evidence fields; it cannot supply governance by itself.

Integration recipes

Apify API

Start a run with the exact JSON contract and a maximum charge appropriate for the intended row count. Poll that one run to terminal. Read default Dataset items and default KVS key OUTPUT. Require OUTPUT.runId to equal the platform run ID, reconcile Dataset count with deliveredRowCount, and reconcile named result-found events with paidRowCount.

Webhook or automation platform

Trigger only on terminal platform status. Fetch OUTPUT before routing rows. Send FAILED, unknown delivery, unknown settlement, and settlement anomaly to an incident queue. Send free diagnostics to a data-quality queue. Send result candidates to a controlled human-review queue, never directly to messaging or medical workflows.

Data warehouse

Use stableId plus sourceName as a source-scoped key. Store requestDigest, inputDigest, observedAt, sourceRetrievedAt, and the run ID. Keep OUTPUT in a separate run-fact table so settlement is not denormalized into a pre-settlement Dataset row. Apply row-level access and a retention policy.

CRM staging

Map only approved minimal fields into a quarantine object. Preserve source and rights labels. Require a reviewer to add the authoritative credential check and lawful contact basis outside this Actor. Do not put the authorization sentence or sourceLicense text into externally visible messages.

MCP or agent workflow

Treat this Actor as a deterministic normalization tool, not an autonomous directory researcher. An agent may propose a review task, but the tool output does not authorize source access, identity resolution, credential conclusions, ranking, or outreach. Pass the exact run ID and evidence gaps to a human.

Replay guard

Store run ID, requestDigest, stable IDs, terminal status, and lastAttempt. A new Actor run can create a new start charge and new result charges even for identical input. replaySafe:false means a linked push was attempted or confirmed and must not be repeated without manual reconciliation.

Operating guide

Before the first production run, archive the provider agreement or internal authority, document the purpose, map recipients, approve the minimal fields, define retention, and designate an incident owner. Begin with one record and a bounded charge cap. Confirm one Dataset row, one current-run OUTPUT, one start event, one named result event, and no unexpected default Dataset event.

During operation, monitor invalidCount, duplicateCount, withheldRowCount, unknownDeliveryCount, unknownSettlementCount, stale freshness, LOW priority, KVS recovery, and platform status. Sudden invalid growth usually means the export contract changed. An unexpected price map, missing current run ID, or nonzero starting result counter fails closed to protect billing truth.

When a run fails before delivery, read the explicit failure stage and replaySafe. When a push throws, delivery may have occurred even though no receipt returned. When a push returns but the named counter cannot be read, Dataset delivery is known but settlement is unknown. The Actor never retries either condition. Reconcile the platform before any intentional new run.

Review the licence and privacy design whenever the source, fields, recipients, purpose, jurisdiction, retention, or provider terms change. Re-run a small acceptance fixture after a contract version change. Keep old Task inputs only long enough to observe the free migration diagnostic and complete a controlled cutover.

Security posture is deliberately small: version 0.2 has no outbound request path, accepts no API key, rejects extra record properties, requires HTTPS syntax, bounds input size, pins Apify SDK dependencies, serializes paid delivery, and validates exact output partitions. This reduces exposure but does not validate the safety of buyer-supplied URLs or the lawfulness of submitted data.

FAQ

Does this Actor scrape Doctoralia?

No. Version 0.2 performs zero network requests. It does not open Doctoralia, recorded profile URLs, APIs, search pages, robots files, or any other directory.

Why keep the technical slug?

The slug preserves existing Tasks and integrations while the public contract moves to an authorized-export product. The title and documentation describe the current behavior.

Does the authorization sentence prove I have rights?

No. It is an explicit buyer attestation and an operational gate. You remain responsible for the licence, lawful basis, purpose, notices, retention, correction, deletion, and downstream sharing.

Are professional names personal data?

They can be. Public professional context does not remove privacy, purpose, accuracy, retention, access, correction, or objection obligations. Obtain jurisdiction-specific advice when needed.

Does a profile prove credentials?

No. The Actor does not contact a regulator, professional body, employer, clinic, or the person. Verify identity and credentials through an appropriate authoritative process.

Can I use the rows for automated outreach?

No. safeToAutomate is false. The output is a human-review artifact, not permission for spam, profiling, harassment, eligibility decisions, or medical targeting.

Does the Actor store phone numbers or email addresses?

The closed input rejects extra fields, so dedicated contact fields, biographies, review text, notes, and patient information are not accepted. Still review source values before submission.

Does it verify the profile URL?

No. It only validates an HTTPS URL without embedded credentials. It does not resolve DNS, follow redirects, fetch content, or prove that the URL is public, safe, current, or controlled by the named person.

What makes a row billable?

A valid authorized professional record becomes a result candidate. It is billed only when the linked Dataset push returns and the named result-found counter proves an exact +1 delta.

Are diagnostics charged as results?

No. Migration and validation diagnostics are pushed without result-found. The automatic Actor start event remains separate.

What if the result charge limit is reached?

A returned Dataset write can settle free when the platform explicitly proves zero named-event delta and a charge-limit receipt. OUTPUT records the free state; downstream code must not infer settlement from the row.

What if delivery is ambiguous?

The Actor does not retry a linked push. A thrown push is unknown delivery; a returned push with unreadable settlement is known Dataset delivery with unknown settlement. Both require manual reconciliation.

Why is scrapedAt present?

It is a backward-compatible field name and equals processing time. Current behavior is not scraping; use observedAt in new integrations.

Can I compare ratings between sources?

Not safely without source-specific normalization. Rating methods, eligibility, moderation, sampling, and time windows differ. The Actor preserves supplied aggregates but makes no cross-source comparability claim.

Is HIGH priority a recommendation to contact the person?

No. It means the submitted record has stronger freshness/locality coverage for manual review. It is not a lead score, clinical judgment, credential conclusion, or contact permission.

Can I submit the same professional from two sources?

Yes; identities remain source-scoped. The Actor will not merge cross-source people automatically because similar names and specialties are insufficient identity evidence.

How long should I retain results?

Only as long as your documented purpose and legal basis require. Establish access controls, a deletion schedule, correction handling, and a withdrawal or objection path before production use.

Does SHA-256 anonymize a person?

No. Stable hashes support joins and integrity checks, but predictable or linkable identifiers can still be personal data or pseudonymous data.

Can I rerun safely?

Only after reading the prior run. Pre-delivery failures can be replay-safe; any attempted linked push is not safe for blind retry because delivery or settlement may already have occurred.

Where is terminal truth?

Use the default KVS OUTPUT record bound to the current platform run ID, together with platform run status and named-event counters. Dataset rows intentionally contain settlement-neutral billing intent.

Sources and rights

Version 0.2 does not access Doctoralia or any other directory. It uses only the JSON records placed in the Actor input by the buyer. Recorded profile URLs are evidence references and are never fetched. There is no fallback scraper, browser automation, proxy route, search endpoint, hidden API, or robots-based assumption.

The buyer must hold a documented right to submit, process, and receive the records for the stated purpose. Depending on the source, that may be an explicit provider licence, ownership of the organizational directory, valid professional consent, or another reviewed authority. The exact authorization sentence is mandatory for result candidates, but it is not a substitute for the underlying agreement or privacy basis.

If records originated from a third-party directory, review that provider's current terms, licence, API/export contract, attribution requirements, field restrictions, retention rules, permitted recipients, security obligations, and withdrawal process before submission. If the agreement does not allow paid downstream delivery, do not use this Actor to bypass it. Obtain permission or choose a source that does.

Professional-directory facts can change and can be wrong. The Actor does not verify identity, professional registration, specialty entitlement, sanctions, discipline, clinic affiliation, availability, reputation, rating methodology, or suitability for care. Official regulator checks and qualified human review remain separate steps.

The output is not medical advice, credentialing, legal advice, a lead list, or a recommendation to contact, hire, rank, promote, exclude, or select a person. Use it as a bounded evidence and reconciliation layer inside a governed workflow.