Match Businesses

Description

The Match Businesses endpoint is the first step in the data enrichment process. It enables users to accurately identify businesses based on their name or domain, returning a unique Business ID that acts as the foundation for all subsequent API interactions. This endpoint is designed to provide high-accuracy business matching by leveraging multiple data sources, validation layers, and proprietary algorithms to ensure precise identification. Once a business is successfully matched, its Business ID becomes the primary key for retrieving enriched company data, accessing financial insights, monitoring real-time business events, and performing additional analytics through other Explorium APIs.

Coverage

Attribute	Coverage Details
Total Businesses	80M+ businesses across 150+ countries
Matching Accuracy	Advanced entity resolution for precise business identification
Real-Time Updates	Ensures the latest business records are used for matching

How It Works

Input: A list of business identifiers, which can include name, website (domain), and linkedin_company_url.
Processing: The system cross-references multiple internal datasets to determine the best possible match.
Output: A structured response containing the matched Business IDs, preserving the exact order of the input list.

Matching Strategy

When using the Business Match endpoint, the system applies a multi-step resolution strategy based on the fields you provide — primarily name and website.

1. Primary Matching — Smart Fuzzy Logic (Name + Website)

We begin by attempting to match the business using both the company name and website domain.
The company name is evaluated using a smart fuzzy matching algorithm designed to handle:

Common variations and abbreviations
Typos and noisy CRM inputs
Token normalization, semantic similarity, and industry-aware string processing

The website (domain) serves as a strong anchoring signal to disambiguate between similarly named companies and to boost confidence.
This phase ensures high-precision matching while remaining robust to imperfect input data.

2. Fallback Matching — Website Only

If the system fails to find a confident match using both name and domain, it automatically falls back to matching by website alone.
Because domains are typically unique and consistent across organizations, this fallback ensures matches can still be returned when the company name is incomplete, inconsistent, or incorrect.

Important Notes

Fallback matching from name + website → website only occurs only when both fields are provided.
If only the website is supplied, it will be used directly for matching.
If only the name is provided, matching relies solely on fuzzy name resolution without domain anchoring.
This logic is aligned with the AgentSource model, which emphasizes main site-level resolution (not individual branches).

Example Scenarios

Input	Matching Outcome
`Name: Starbucks EMEA`, `Website: starbucks.com`	Match using name + website (fuzzy supported)
`Name: abcxyz`, `Website: starbucks.com`	Fallback — match using website only
`Name: Starbucks`, `Website: fakeurl.xyz`	No match — invalid domain
`Name: (empty)`, `Website: starbucks.com`	Match using website only
`Name: Starbuks Intl Ltd`, `Website: starbucks.com`	Match using fuzzy logic + website

Recommendation

To get the best possible results:

Always include both name and website when calling the Business Match endpoint.
This enables the system to apply smart fuzzy matching and fallback recovery for unmatched names — maximizing accuracy, coverage, and confidence.

Schema Explanation

Field	Type	Description
`businesses_to_match`	Array	List of business identifiers to match (can include name, domain, LinkedIn)
`name`	String	Business name provided for matching
`domain`	String	Business domain provided for matching
`linkedin_url`	String	LinkedIn company profile URL (optional, improves matching accuracy)
`business_id`	String	Unique identifier for the matched business (null if not found)

Best Practices

Always store the Business ID – It serves as the key for all future enrichment and analytics.
Use multiple identifiers (e.g., name + domain, or LinkedIn URL) for higher match accuracy.
Batch requests efficiently to optimize API performance.
Handle null values gracefully to account for unmatched businesses.
Update and validate input data regularly to ensure the most accurate matches.

Body Params – Example with LinkedIn URL

{
  "request_context": {
    "seller_id": "sample_seller"
  },
  "businesses_to_match": [
    {
      "name": "microsoft",
      "linkedin_url": "https://linkedin.com/company/microsoft"
    }
  ]
}

For detailed endpoint explanations, request examples, and integration tips, explore the documentation sections above.

Body Params - Try Me Example

name: Apple
domain: apple.com

name: Microsoft
domain: microsoft.com

Authorizations

api_key

string

header

required

Body

application/json

businesses_to_match

BusinessMatchInput · object[]

required

Required array length: 1 - 50 elements

Show child attributes

businesses_to_match.name

string

Maximum string length: 256

businesses_to_match.domain

string

businesses_to_match.url

string

businesses_to_match.linkedin_url

string

request_context

Request Context · object

Example:

null

Response

Successful Response

This is base response model for all responses in partner service.

response_context

ResponseContext · object

required

Show child attributes

response_context.correlation_id

string

required

response_context.request_status

enum<string>

required

The RequestStatus class is an enumeration that defines the possible statuses of a request.

This enum is used to indicate whether a request was successful, missed, or failed. It ensures consistent handling of request statuses across the application.

Attributes: SUCCESS: Indicates that the request was successfully processed. MISS: Indicates that the request did not find any matching data. FAILURE: Indicates that the request encountered an error or failure.

Available options:

success,

miss,

failure

response_context.time_took_in_seconds

number

required

total_results

integer

required

The total_results number matched businesses

total_matches

integer

required

The total number of matches.

Required range: x >= 0

matched_businesses

(BusinessMatchOutputWithErrors · object | BusinessMatchOutput · object)[]

A list of all businesses. If they not matched business_id will None.

BusinessMatchOutputWithErrors
BusinessMatchOutput

Show child attributes

matched_businesses.error

string

required

matched_businesses.error_type

string

required

matched_businesses.input

BusinessMatchInput · object

Show child attributes

matched_businesses.input.name

string

Maximum string length: 256

matched_businesses.input.domain

string

matched_businesses.input.url

string

matched_businesses.input.linkedin_url

string

matched_businesses.business_id

string

Explorium AgentSource

Partners

Description

How It Works

Matching Strategy

1. Primary Matching — Smart Fuzzy Logic (Name + Website)

2. Fallback Matching — Website Only

Important Notes

Example Scenarios

Recommendation

Body Params - Try Me Example

Authorizations

Body

Response

Explorium AgentSource

Partners

​Description

​How It Works

​Matching Strategy

​1. Primary Matching — Smart Fuzzy Logic (Name + Website)

​2. Fallback Matching — Website Only

​Important Notes

​Example Scenarios

​Recommendation

​Body Params - Try Me Example

Authorizations

Body

Response

Description

How It Works

Matching Strategy

1. Primary Matching — Smart Fuzzy Logic (Name + Website)

2. Fallback Matching — Website Only

Important Notes

Example Scenarios

Recommendation

Body Params - Try Me Example