DEV Community

Cover image for Reconcile registry observations with typed company identifiers
Tim Zinin
Tim Zinin

Posted on

Reconcile registry observations with typed company identifiers

I maintain this Actor. This is an AI-assisted technical walkthrough, fact-checked against its accepted source contract and saved acceptance evidence.

Company records are easy to join badly. A matching name can look persuasive while an identifier belongs to a different registry. A record containing both an LEI and a company number can also tempt an importer to collapse two identifier systems without preserving the evidence for the bridge.

The Corporate Registry Conflict Resolver processes supplied registry observations into identity assessments. It separates typed identifiers, flags conflicting fields, and proposes reviewable merge candidates. It does not verify ownership, solvency, or current legal status. It also does not launch upstream collection Actors or fetch registry pages.

Validate the key before comparing attributes

The LEI path validates identifier shape and checksum. A UK company number needs the supported eight-character form and the appropriate UK prefix rules, or eight digits. Context matters: a bare companyNumber in an unknown source is not automatically a UK identifier. The supported source adapter or an explicit typed identity supplies that context.

Names remain observations associated with these keys. Name-only matching does not trigger an automatic merge. This makes the result easier to integrate safely: store the identifier type and value as separate columns and preserve the source evidence that led to the assessment. Do not discard the type just because both identifiers happen to fit the same string column.

A bridge is a review object

When one source record carries both identifier types, it can support a bridge candidate. That is evidence for a proposed relationship between typed identities, not a reason to silently unify every observation under one guessed master record. Keep bridge candidates alongside conflicts and let a separate controlled process decide how your master-data system should use them.

The saved acceptance example has status no_conflicts_observed, action propose_merge_candidate, and medium confidence. Read that literally: no conflicts were observed in that supplied evidence. It does not prove that the records are universally consistent or that the organization is currently active. Field names such as blockedFields, bridgeCandidates, and evidence make the assessment basis available for inspection.

Preserve disagreement in the export

Legal status, names, incorporation dates, and classifications can disagree across observations. A last-write-wins merge removes that disagreement from view. A better import stores the assessment and its evidence before applying any chosen precedence policy. If you later revise that policy, the original observations remain available to explain the change.

For acceptance, compare an explicitly typed UK record with an unknown-source bare number, an invalid-checksum LEI, and a record carrying both identifier types. Use synthetic data only when it is clearly labelled. Confirm that unknown identifiers do not gain a jurisdiction by guesswork and that bridge candidates remain inspectable. Check omitted-evidence counts before calling the displayed detail complete. Personal fields excluded by the product should remain excluded in your own public examples and reporting.

Run a small saved snapshot

Start with an existing Dataset you are authorized to read. Replace the Dataset placeholder below with its actual ID. Supported input can also use a source run ID or inline records; choose one explicit source. This Actor does not launch the upstream collection for you.

curl --request POST \
  'https://api.apify.com/v2/acts/zinin~corporate-registry-conflict-resolver/runs?maxTotalChargeUsd=0.10' \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{"datasetId":"REPLACE_WITH_YOUR_DATASET_ID","maxInputRows":100,"maxResults":10}'
Enter fullscreen mode Exit fullscreen mode

The response identifies an asynchronous run. Save that run ID and check its status before reading its default Dataset. A client timeout does not cancel a server run; inspect the existing ID before starting another one. maxInputRows bounds ingestion and maxResults caps useful output. Neither option establishes complete coverage of a larger source. The API charge limit is a ceiling, not a promise that ten results will fit.

Price and evidence limits

On 15 October 2026 the observed FREE-plan price is $0.035 per identity assessment, with no paid start event for this Actor. Other subscription tiers can have different prices; verify the current Actor page before use. Source collection is a separate activity and may carry its own charges. Free diagnostic rows do not count as paid useful assessments.

The examples discussed here come from saved owner acceptance runs. They show specific observed behavior, rather than customer acceptance, profitability, or an exhaustive guarantee for every input. A new run of identical input can be charged again without adding new source evidence. Retain input provenance, the actual build ID, and the source observation window when comparing results over time.

Top comments (0)