Apify Public Data & Leads

Florida Sunbiz Officer and Registered Agent Search

florida_officer_search

Read-only

Find every Florida company tied to a person by searching Sunbiz officer, director, or registered-agent names. Returns entity names and document numbers for background research or ownership mapping.

Instructions

Search the Florida Sunbiz registry by an officer, director, or registered-agent name and return every Florida company tied to that person, with entity name and document number.

Behavioral Transparency:

Execution: Network call executed synchronously in the cloud via Apify Actor 'captainhandsome/fl-sunbiz-officer-search'.
Side Effects: Reads public sources and creates a billed Actor run and dataset on your Apify account.
Authentication: Requires APIFY_TOKEN environment variable.
Latency & Limits: Typical run duration is 10-30 seconds without detail pages, longer with include_details enabled (one extra page load per matched company); timeout capped at 120 seconds.

Usage Guidelines:

When to use: Use to find every Florida company associated with a specific person's name (officer, director, or registered agent), for background research or ownership mapping.
When NOT to use: Do not use to search by company name (use 'florida_new_filings_search' instead), for other states, or for contractor licences.
Named alternatives: Use 'florida_new_filings_search' to look up a Florida company by its own name, or 'us_business_entity_search' for a multi-state company-name lookup.

Input Schema

TableJSON Schema

Name	Required	Description
`max_results`	No	Maximum number of officer-to-entity records to return and bill. Defaults to 10.
`search_query`	Yes	Full or partial officer, director, or registered-agent person name to search on Sunbiz (e.g. 'SMITH' or 'Smith, John').
`include_details`	No	When true, opens each matched company's Sunbiz detail page to add status, filing date, FEI/EIN, addresses, the full officer list, and annual-report history. Slower; leave off for a fast person-to-company lookup.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`run`	No
`error`	No
`status`	Yes
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedv1.1.0Sep 15, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedOutput schema / properties / error
```
Added value: +{
+  "type": "object"
+}
```

removedOutput schema / properties / results / description

Removed value: -"Collection of Florida officer/registered-agent-to-entity records matching the search query."

changedOutput schema / properties / results / items / properties / date_filed / description

Previous value: -"Date the entity was first filed with the Florida Division of Corporations (requires include_details)."New value: +"Date the entity was first filed with the Florida Division of Corporations, as MM/DD/YYYY."

addedOutput schema / properties / results / items / properties / date_filed / title
```
Added value: +"Date filed"
```

changedOutput schema / properties / results / items / properties / detail_url / description

Previous value: -"Direct link to the company's Sunbiz detail page for audit against the state registry."New value: +"Direct link to the company's Sunbiz detail page, so any record can be audited against the state registry."

addedOutput schema / properties / results / items / properties / detail_url / title
```
Added value: +"Sunbiz record URL"
```
addedOutput schema / properties / results / items / properties / document_number / title
```
Added value: +"Document number"
```
addedOutput schema / properties / results / items / properties / entity_name / title
```
Added value: +"Entity name"
```

changedOutput schema / properties / results / items / properties / entity_type / description

Previous value: -"Registry classification, such as Florida LLC or Foreign Profit Corporation (requires include_details)."New value: +"Registry classification, such as Florida Limited Liability Company or Foreign Profit Corporation."

addedOutput schema / properties / results / items / properties / entity_type / title
```
Added value: +"Entity type"
```
addedOutput schema / properties / results / items / properties / officer_name / title
```
Added value: +"Officer or agent name"
```

changedOutput schema / properties / results / items / properties / principal_address / description

Previous value: -"Principal place of business on file (requires include_details)."New value: +"Principal place of business on file, street through ZIP as one line."

addedOutput schema / properties / results / items / properties / principal_address / title
```
Added value: +"Principal address"
```

changedOutput schema / properties / results / items / properties / status / description

Previous value: -"Current Florida registration status, normally ACTIVE or INACTIVE (requires include_details)."New value: +"Current Florida registration status, normally ACTIVE or INACTIVE."

addedOutput schema / properties / results / items / properties / status / title
```
Added value: +"Entity status"
```
addedOutput schema / properties / run
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / status

Added value: +{
+  "enum": [
+    "success",
+    "empty_unverified",
+    "partial",
+    "error"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "results"
-]New value: +[
+  "results",
+  "status"
+]

Addedv1.0.11Sep 13, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses synchronous network execution, the specific Apify Actor, billing and dataset creation side effects, the APIFY_TOKEN requirement, typical latency, and the 120-second timeout. This goes well beyond the readOnly/destructive annotations and gives the agent the operational context needed to call the tool safely. The billed run/dataset is a platform artifact rather than a mutation of the searched registry, so it does not contradict readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in one clear sentence, followed by well-labeled Behavioral Transparency and Usage Guidelines sections. Every bullet adds distinct value with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, the description covers authentication, cost, latency, output shape, parameter trade-offs, and sibling alternatives. An output schema exists, so the description does not need to repeat return-value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes all three parameters well (100% coverage), so the baseline is 3. The description adds extra operational meaning beyond the schema by explaining that max_results controls billed records and that include_details incurs an extra page load per matched company, which helps agents reason about cost and latency.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact action ('Search the Florida Sunbiz registry by an officer, director, or registered-agent name') and the concrete result ('every Florida company tied to that person, with entity name and document number'). This clearly distinguishes it from sibling company-name search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit 'When to use' and 'When NOT to use' guidance, and names specific alternatives: 'florida_new_filings_search' for company-name lookups and 'us_business_entity_search' for multi-state searches. An agent is fully routed to the correct tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.