Choose a Reliable
Free Company Profile API如何选择可靠的
免费公司概况 API
Learn which company fields matter, how free plans differ, and how to validate an API before your application depends on it.
了解关键公司字段、免费套餐差异与质量检查方法，
在应用正式接入 API 前完成可靠性验证。
TL;DR核心摘要
A company profile endpoint turns a ticker, domain, LEI, or internal identifier into a structured business record.
Free access usually includes request caps, delayed updates, restricted redistribution, or narrower geographic coverage.
Measure identifier match rate, field completeness, data freshness, response stability, and documented error behavior.
QVeris helps agents discover and inspect company-data capabilities before making an auditable tool call.
公司概况接口可根据股票代码、域名、LEI 或内部标识，返回结构化的企业档案数据。
免费访问通常设有请求次数上限；此外，数据更新可能滞后，数据再分发可能受限，覆盖地区也可能较少。
应评估标识匹配率、字段完整性、数据时效和接口响应稳定性，并确认文档是否清楚说明错误响应及其处理方式。
QVeris 帮助 AI 智能体查找并检查可用的公司数据查询能力，再发起可审计的工具调用。
Use a company profile API to answer “which organization is this?” and provide stable descriptive context—not to replace financial statements or a fundamentals dataset. It fits entity resolution, search results, CRM enrichment, supplier onboarding, screening, and linking records across filings or market data. The response should distinguish a legal entity, operating brand, parent, subsidiary, and listed security instead of collapsing them into one company name.
公司概况 API 主要回答“这究竟是哪一家机构”，并提供稳定的描述性背景，不能替代财务报表或基本面数据集。它适合企业身份识别、搜索结果、CRM 数据补全、供应商接入、筛选，以及在监管文件和市场数据之间关联记录。响应应区分法定主体、经营品牌、母公司、子公司和上市证券，不能把它们都压缩成一个公司名称。
Fields a useful company profile API should provide实用的公司概况 API 应返回哪些字段
A useful profile is more than a legal name. It should identify the business consistently and provide enough context for search, screening, enrichment, analytics, or CRM workflows. Start with the fields your product truly consumes, because a long schema does not guarantee strong coverage.
实用的公司概况不能只有法定名称，还应能够一致地识别企业，并为搜索、筛选、数据补全、分析和 CRM 工作流提供足够的上下文。首先应明确产品实际需要哪些字段，因为接口返回的字段再多，也不代表每个字段都有充分的数据覆盖。
Look for legal and display names, ticker and exchange, domain, LEI, CIK, ISIN, and a provider-stable company ID. Multiple identifiers make deduplication and cross-provider joins safer.
Industry, sector, SIC or NAICS codes, headquarters address, country, and operating status support segmentation. Confirm whether classifications are standardized or provider-specific.
Identify the legal name, jurisdiction, registration or LEI where available, parent, subsidiaries, operating brands, and ultimate owner. A listed security issuer may not be the customer-facing brand shown on a website.
Keep primary listing, share class, exchange, ticker effective dates, IPO or incorporation date, active, acquired, dissolved, private, or delisted status, and successor relationships.
Useful descriptive fields include a sourced business summary, products or services, official website, verified domains, logo reference, contact channels, and social profiles. Separate verified facts from provider-generated descriptions.
Employee range, revenue band, funding stage, public or private status, and headquarters can support segmentation, but each field needs a source, period, unit, confidence, and update time.
Record where each attribute came from, when it was observed, when the underlying fact became effective, whether it was inferred, and whether a later source corrected it. One profile-wide updated date is often insufficient.
应关注法定名称与常用名称、股票代码及对应交易所、域名、LEI、CIK、ISIN，以及由服务商分配且长期保持不变的公司 ID。组合使用多种标识有助于数据去重，也能更可靠地关联不同服务商的数据。
所属行业、产业部门、SIC 或 NAICS 代码、总部地址、所在国家及经营状态均可用于企业分群。还应确认这些分类采用统一的标准体系，还是由服务商自行定义。
在可取得时，保存法定名称、注册司法辖区、注册号或 LEI、母公司、子公司、经营品牌和最终所有人。上市证券的发行主体未必就是网站上面向客户展示的品牌。
保存主要上市地、股份类别、交易所、股票代码有效日期、IPO 或成立日期，以及正常经营、被收购、注销、非上市或退市状态和后续主体关系。
实用的描述字段包括有来源的业务简介、产品或服务、官方网站、经验证域名、Logo 引用、联系方式和社交主页。应把已核实事实与服务商生成的描述分开。
员工区间、营收区间、融资阶段、上市或非上市状态及总部位置可以支持分群，但每个字段都应带有来源、期间、单位、可信度和更新时间。
记录每个属性来自哪里、何时观测、事实何时生效、是否通过推断生成，以及后续来源是否进行更正。只提供一个整份概况的更新时间通常不够。
How to compare limits and validate an API如何比较使用限制并验证 API 可靠性
| Limit限制维度 | Question to ask需要确认的问题 | Production risk生产环境风险 |
|---|---|---|
| Request quota请求配额 | Is the cap per minute, day, key, account, or endpoint?请求配额是按每分钟、每天、API 密钥、账户还是接口端点计算？ | Batch enrichment may stop halfway.批量数据补全任务可能中途停止。 |
| Coverage数据覆盖 | Are private firms, inactive entities, and international markets included?数据是否覆盖非上市公司、已停业企业以及海外市场中的企业？ | Missing firms can bias analysis.企业记录缺失可能导致分析结果出现偏差。 |
| Freshness数据时效 | How often is each field updated, and is an updated timestamp returned?各字段多久更新一次，响应中是否包含最近更新时间戳？ | Stale status or employee data may mislead users.过时的经营状态或员工人数数据可能误导用户。 |
| Usage rights数据使用许可 | Can results be cached, displayed, exported, or redistributed?返回结果是否允许缓存、展示、导出或再分发？ | A technically free API may not fit the product license.即使 API 本身免费，其数据使用许可也可能不符合产品的授权要求。 |
| Match quality匹配质量 | Does lookup return confidence, matched field, alternatives, and ambiguity?查询是否返回可信度、命中字段、候选项和歧义说明？ | The wrong company can be enriched with plausible data.错误公司可能被补全为看似合理的数据。 |
| Identity model身份模型 | Are company, legal entity, brand, domain, and listed security separate?公司、法定主体、品牌、域名和上市证券是否分别建模？ | Duplicates and parent-subsidiary confusion spread downstream.重复记录和母子公司混淆会扩散到下游。 |
| Field provenance字段来源 | Does each important field have source, observed time, and confidence?重要字段是否包含来源、观测时间和可信度？ | Users cannot resolve conflicting profile values.用户无法处理互相冲突的概况信息。 |
| Error semantics错误语义 | Are not found, ambiguous, inactive, forbidden, and throttled distinct?未找到、存在歧义、已失效、无权限和限流是否明确区分？ | Automation may turn uncertainty into a false match.自动化流程可能把不确定结果当成错误匹配。 |
Worked identity-resolution example公司身份解析示例
Suppose an enrichment request contains the display name “Atlas Systems,” ticker ATS, and the domain atlas.example, but no exchange. The API returns two plausible candidates. Candidate A is a public parent whose primary listing uses ATS on one exchange; its legal name, CIK, and active ticker dates agree, while the submitted domain belongs to a wholly owned operating subsidiary. Candidate B is a private company with the same display name and a matching country, but no ticker, CIK, or ownership relationship to the domain. A name-only lookup may rank both highly even though only Candidate A explains all supplied evidence.
The resolver should preserve the submitted values, candidate IDs, matched and conflicting fields, score components, and the parent-subsidiary link. It may auto-resolve Candidate A only when the required evidence and lead over Candidate B meet a documented threshold. If the exchange is missing and the ticker is reused in another market, or if the domain is shared by several group companies, return ambiguous and request an exchange, LEI, CIK, registration number, or other discriminator. After resolution, attach the profile to the stable company ID; keep the listing and ticker as dated child records so a rebrand, delisting, ADR termination, or ticker change does not create a new company or rewrite history.
公司身份解析示例
假设一条数据补全请求只提供了常用名称“Atlas Systems”、股票代码 ATS 和域名 atlas.example，却没有交易所。API 返回两个看似合理的候选项：候选 A 是一家上市母公司，其主要上市证券在某交易所使用 ATS，法定名称、CIK 和股票代码有效期可以互相印证，而请求中的域名属于它的全资经营子公司；候选 B 是同名非上市公司，所在国家相同，但没有对应股票代码、CIK，也无法证明它与该域名存在所有权关系。只按名称查询时，两者得分可能都很高，但只有候选 A 能解释全部已知证据。
解析器应保留用户提交的原始值、候选 ID、命中与冲突字段、各评分项，以及母子公司关系。只有当候选 A 满足书面规定的必要证据，并且领先候选 B 的差距达到阈值时，才能自动确认。如果交易所缺失且该代码在其他市场也被使用，或域名由集团内多家公司共用，就应返回 ambiguous，要求补充交易所、LEI、CIK、注册号或其他区分信息。身份确认后，应把概况数据关联到稳定公司 ID；上市证券和股票代码则作为带有效日期的子记录保存，这样公司更名、退市、ADR 终止或代码变更时，既不会生成一家“新公司”，也不会改写历史。
Include a public issuer, private firm, subsidiary, acquired company, rebrand, shared domain, holding company, foreign entity, and multiple listings. Verify every result against authoritative records.
Normalize the input, generate candidates, score identifiers, require a margin over the second candidate, and route ambiguous matches to review before attaching profile fields.
Keep field value, source, observed time, effective period, confidence, and replacement relation so conflicting addresses, names, classifications, or employee counts remain explainable.
Legal identity changes slowly; status, domains, leadership, employee ranges, and descriptions can change faster. Schedule refresh and expiry policies per attribute.
Track match, ambiguous, no-result, stale-field, conflict, and manual-correction rates by country, identifier type, company class, and provider version.
样本应包括上市发行人、非上市企业、子公司、被收购公司、更名企业、共享域名、控股公司、境外主体和多地上市公司，并逐条与权威记录核对。
先标准化输入并生成候选，根据标识计算匹配得分，要求第一候选与第二候选之间达到足够差距；存在歧义时先人工复核，再附加概况字段。
分别保存字段值、来源、观测时间、有效期间、可信度和替代关系，使互相冲突的地址、名称、分类或员工数仍然可以解释。
法定身份变化较慢，经营状态、域名、管理层、员工区间和业务描述可能变化更快。应按属性分别制定刷新和过期政策。
按国家或地区、标识类型、公司类别和服务商版本统计匹配、歧义、无结果、字段过期、冲突和人工更正比例。
Use QVeris to find company profile capabilities使用 QVeris 查找公司概况数据能力
QVeris gives AI agents a capability-routing layer for discovering, inspecting, and calling external tools. Instead of hardcoding the first company API you find, an agent can inspect available capabilities and select an appropriate source for the task.
QVeris 为 AI 智能体提供能力路由层，用于查找、查看和调用外部工具。智能体不必将找到的第一个公司数据 API 硬编码到程序中，而是可以先了解有哪些可用能力，再根据具体任务选择合适的数据源。
- Search for company profiles, identifiers, filings, fundamentals, or enrichment capabilities from one entry point.
- Inspect a tool contract before calling it, including required identifiers and returned fields.
- Keep capability calls observable when company data becomes part of an automated agent workflow.
- 通过统一入口查找公司概况、企业标识、监管申报文件、基本面数据和数据补全等能力。
- 调用工具前查看其接口约定，包括必填标识和返回字段。
- 如果公司数据将用于自动化智能体工作流，应确保每次工具调用均可观测、可追溯。
QVeris can simplify discovery and routing across company-data capabilities. The application still owns entity resolution, ambiguity review, parent-subsidiary modelling, field-level provenance, refresh policy, licensing, and how generated or inferred descriptions are labelled.
QVeris 能够简化公司数据能力的查找与路由，但企业身份识别、歧义复核、母子公司建模、字段级来源、刷新政策、许可，以及生成或推断描述的标注方式，仍由应用方负责。
FAQ常见问题
It can be suitable for a small workload if the quota, license, coverage, support, and service expectations match your product. Keep an upgrade or fallback plan.
Many APIs support domain lookup, but domains can be shared, redirected, or owned by a parent company. Validate the returned legal entity before trusting the match.
No single identifier works everywhere. Use a stable provider ID internally and retain standard identifiers such as LEI, CIK, ISIN, ticker plus exchange, and domain when available.
如果请求配额、授权条款、数据覆盖范围、技术支持和服务保障都符合产品需求，免费 API 可以用于规模较小的生产场景，但仍应提前准备升级或备用方案。
许多 API 支持按域名查询公司，但同一域名可能由多家公司共用，也可能被重定向，或登记在母公司名下。因此，在确认匹配结果前，应先核验返回的法定主体。
没有一种标识适用于所有场景。内部系统可使用服务商提供的稳定公司 ID；如果能够获取，还应保留 LEI、CIK、ISIN、股票代码及对应交易所、域名等标准标识。
A profile API describes identity, classification, location, status, relationships, and web presence. A fundamentals API focuses on financial metrics and periods. Use separate models and join by stable company ID.
Return ranked candidates with evidence and confidence, then require clarification or review when the top match is not decisive. Do not silently attach data to the first name or domain match.
Often no. It may be self-reported, estimated, rounded, sourced from a different date, or represent one subsidiary. Preserve the range, source, scope, observation date, and confidence.
Keep the stable entity ID, old and new names, effective dates, change type, source, and aliases. Overwriting the old name breaks historical matching and audit trails.
概况 API 描述身份、分类、所在地、状态、公司关系和网络信息；基本面 API 关注财务指标及其报告期间。两者应分别建模，再通过稳定公司 ID 关联。
应返回带证据和可信度的候选排名；第一候选不够明确时，要求补充信息或人工复核，不能静默采用第一个名称或域名匹配。
通常不可以。它可能来自企业自报、估算或取整，也可能对应不同日期或只覆盖某个子公司。应保留区间、来源、统计范围、观测日期和可信度。
应保留稳定主体 ID、变更前后名称、生效日期、变更类型、来源和别名。直接覆盖旧名称会破坏历史匹配和审计记录。