Wisconsin Business Entity Search

Search the Wisconsin Department of Financial Institutions corporate register by company name and export entity IDs, registered names, registration classes, effective dates and status as JSON, CSV, Excel or XML. No API key is required. Give it a name and the Actor submits the register's public search form for you, so you never have to build a URL; if you already hold a DFI results link you can pass that instead. A common surname fills the register's entire 500-row result page from a single request, so set max_items before each run.

What data can I extract?

• entity_id, the DFI identifier for the entity, taken from the register's ID column
• entity_name, the registered name as the register publishes it, normalised to lower case
• entity_type, Wisconsin's own registration class as code and label together, such as 12 - domestic limited liability company or 02 - foreign business corporation
• registered_date, the registration effective date in MM/DD/YYYY
• status, the current register status, including dissolved and historical states

Turn on Fetch full detail records (include_details) and each result is joined to its own DFI record page, adding nine more fields:

• registered_agent and registered_office, the agent on file for service of process and that agent's Wisconsin office address
• principal_office, the entity's principal place of business, often out of state
• period_of_existence, PER for a perpetual charter, otherwise the expiry the register holds
• last_annual_report_year, the newest annual report on file, the quickest read on whether a vendor is current
• previous_name, the name the entity traded under immediately before its current one
• foreign_state, foreign_organization_date and paid_capital_represented, recorded for entities organised outside Wisconsin

Detail mode costs one extra request per record, so leave it off for a fast name-and-status lookup.

Values are Unicode-normalised, whitespace-collapsed and lowercased, so they join, dedupe and match against other datasets without further cleaning. Every result is written to the default dataset and can be downloaded as JSON, CSV, Excel or XML, or retrieved through the Apify API.

One search term returns up to 500 records. A live search for SMITH returns 500 rows, JOHNSON returns 500, and a narrower term such as ACME returns 249, so the ceiling is the register's own page limit rather than a limit of this Actor.

Input example

{
  "search_terms": ["SMITH"],
  "max_items": 10
}

search_terms takes one or more full or partial business names. max_items is a hard ceiling on records emitted, and therefore on what a run can cost. The default input is deliberately small so a first run is cheap to inspect.

start_urls is accepted as an alternative for anyone who already has a DFI results link, in the form https://apps.dfi.wi.gov/apps/corpsearch/Results.aspx?type=Simple&q=SMITH. Supply one or the other; search_terms takes precedence if both are set.

This matters more here than on most registries. A single common surname can produce 500 billable records from one term, so the cap is doing real work.

Output example

One record, taken verbatim from this Actor's own dataset:

{
  "entity_id": "1s21620",
  "entity_name": "smith, inc.",
  "entity_type": "01 - domestic business",
  "registered_date": "11/01/1979",
  "status": "involuntarily dissolved"
}

entity_id and entity_name are present on every record. registered_date comes back as an empty string when the register holds no date: in the 500-row reference search that was 10 records, every one of them a 97 - in process filing with status name conflict or in process. That is the source's own data rather than a gap in extraction.

Common use cases

• Building Wisconsin lead lists filtered by registration class and formation date
• Entity resolution and vendor onboarding, confirming that a counterparty is actually registered in Wisconsin
• Due diligence checks, separating entities in good standing from administratively dissolved ones
• Tracking formations and dissolutions over time, and enriching CRM records with a registry identifier

Use with AI agents and MCP

Apify's MCP server can discover and call this Actor from an AI workflow. Example intent:

Find up to 25 Wisconsin entities matching "Smith" and tell me which are still in good standing.

Use the JSON from Input example as the tool arguments. The input schema is strict and rejects unsupported parameters, and the dataset schema documents each returned field with a real example value, so an agent can interpret results without guessing.

Pricing and cost control

Output is billed per result at $0.004 per result (about $4.00 per 1,000 results), plus a $0.0005 Actor-start charge billed once per gigabyte of memory at run start. Use max_items to cap both output volume and charges. The price shown on the Apify Store listing is authoritative.

max_items is the only control you need: it caps output and billable results together, across all search terms in a run. You are not billed for the platform time the Actor spends running.

Reliability

The Actor runs over plain HTTP with no browser, which keeps runs fast and cheap. Extraction is row-wise, meaning one record per result row with every field resolved inside that row, so a record missing an optional value yields a null or empty string for that record only and never shifts the records that follow.

An automated monitor checks the target against the live site, re-derives selectors when the page changes, and validates candidates against two independent probe searches plus a schema contract before anything ships. A sentinel run must return at least 30 records with valid fields, and a target that fails three checks in a row is quarantined rather than left to return silent rubbish.

Limitations and responsible use

• Detail records are rate-limited by DFI. The search itself is unthrottled, but the register's per-entity record pages are served sparingly to any one client, so include_details suits small batches rather than a full 500-row page. Detail pages that the register declines are returned as nulls on an otherwise complete record rather than failing the run. Officers and the full filing history are not extracted.
• Wisconsin only. Other states run different systems.
• Name search only. There is no lookup by entity ID, registered agent or address.
• 500 records per search term is the register's page limit. Use narrower terms to reach entities beyond it.
• Results are lowercased by design. Restore display casing yourself if you need it.
• Results include dissolved, withdrawn and historical entities. Filter on status if you only want live ones.

Wisconsin corporate registrations are public records published by the Department of Financial Institutions. This Actor submits the same public search form a visitor would and collects nothing behind a login. You remain responsible for how the data is used, including applicable marketing and data-protection rules, and for validating records before making consequential decisions.

FAQ

Do I need my own API key or account with the registry?

No. The register is public and this Actor needs no customer-supplied credentials.

How do I control what a run costs?

Set max_items. It is a hard ceiling on records emitted and billed. Start at 10, inspect the output, then scale.

Why is everything lowercase?

Field values are normalised so they can be joined, deduplicated and matched against other sources without cleaning. Apply your own display casing downstream.

Why is registered_date sometimes empty?

Because the register has no effective date for that filing. Those records are in-process names and name conflicts, which never completed registration.

How many records will one search term return?

Up to 500, which is the register's own result-page limit. Common surnames reach it; more specific terms return fewer.

Can I export the results?

Yes. Download the default dataset as JSON, CSV, Excel or XML, or pull it through the Apify API.

Can an AI agent call it?

Yes. The Actor has a strict input schema and a documented output schema and can be called through Apify's MCP tooling.