Entity resolution, as an API.

The hard part of public data is not finding records, it is knowing which ones are the same company. Amalgament resolves entities across sources on the identifiers that survive between them (UEI, EIN, registration and parcel keys), so one business is one entity even when it appears in sixteen datasets. Entity resolution is a join, not a name match.

What's in the record

• One canonical entity per real-world business, resolved across sources
• Links built on strong shared identifiers, never on name alone
• Confidence tiers kept separate: strong-ID, name-plus-address, and name-only
• The full record trail attached to each resolved entity

Where it comes from

The same US public records the platform already carries: state registrations, licenses, filings, spending, and property. Resolution runs across all of them on shared identifiers, so the join gets stronger as coverage grows.

What people build with it

KYB and onboarding flows that must know a company is one company, diligence tools assembling a counterparty's full footprint, and any product that needs a stable entity id instead of a pile of near-duplicate names.

One call

curl -H "X-API-Key: $OPENFOLIO_KEY" \
  "https://api.amalgament.com/entity?q=sak+construction"

Common questions

How is this different from fuzzy name matching?

Name matching guesses; entity resolution decides. Amalgament leans on strong shared identifiers and treats a name as a weak hint, so two different companies that share a name stay separate, and one company written many ways still resolves to one entity.

What happens when the evidence is weak?

It stays separate. Precision beats recall here: a wrong merge would attach one company's liens or lawsuits to another, so records only join when the identifiers actually connect them.

More record types: Businesses · Property · Courts · Filings · All record types