Apify Public Data & Leads

Florida Sunbiz Business Entity Search

florida_new_filings_search

Read-only

Search Florida's Sunbiz registry by company name to retrieve entity type, status, and document number, and monitor new business filings.

Instructions

Search the Florida Division of Corporations (Sunbiz) business registry by company name, returning entity name, document number, status, and entity type.

Behavioral Transparency:

Execution: Network call executed synchronously in the cloud via Apify Actor 'captainhandsome/fl-sos-new-filings'.
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; timeout capped at 120 seconds.

Usage Guidelines:

When to use: Use for Florida LLC/corporation lookup by company name, due-diligence checks, or monitoring new Florida business filings.
When NOT to use: Do not use to search by a person's or officer's name (use 'florida_officer_search' instead), for other states, or for contractor licences.
Named alternatives: Use 'florida_officer_search' to find companies tied to a person or registered agent, 'us_business_entity_search' for a multi-state lookup that includes Florida, or 'alabama_business_search' for Alabama-only records.

Input Schema

TableJSON Schema

Name	Required	Description
`max_results`	No	Maximum number of entity records to return and bill. Defaults to 10.
`search_query`	Yes	Full or partial Florida business name to search on Sunbiz (e.g. 'SMITH' or 'Smith Services LLC').
`include_details`	No	When true, opens each result's Sunbiz detail page to add date filed, FEI/EIN, registered agent, principal/mailing addresses, officers, and annual-report history. Slower; leave off for a fast name-and-status 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.

Changed20 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 Sunbiz business-entity records matching the search query."

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

Previous value: -"Date the entity was filed with the Florida Division of Corporations (requires include_details)."New value: +"Date the entity was filed with the Florida Division of Corporations."

addedOutput schema / properties / results / items / properties / date_filed / title
```
Added value: +"Date filed"
```
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: -"Florida registry classification, such as a domestic or foreign LLC or corporation."New value: +"Florida registry classification, such as a domestic or foreign profit corporation or limited liability company."

addedOutput schema / properties / results / items / properties / entity_type / title
```
Added value: +"Entity type"
```

changedOutput schema / properties / results / items / properties / fei_ein / description

Previous value: -"Federal employer identification number on file with the state, where recorded (requires include_details)."New value: +"Federal employer identification number on file with the state, where one is recorded."

addedOutput schema / properties / results / items / properties / fei_ein / title
```
Added value: +"FEI/EIN number"
```

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

Previous value: -"Principal place of business on file with the state (requires include_details)."New value: +"Principal place of business on file with the state."

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

changedOutput schema / properties / results / items / properties / registered_agent / description

Previous value: -"Name of the entity's Florida registered agent (requires include_details)."New value: +"Name of the entity's Florida registered agent. Null when the state records no agent."

addedOutput schema / properties / results / items / properties / registered_agent / title
```
Added value: +"Registered agent"
```

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

Previous value: -"Entity status displayed in the Sunbiz result (e.g. Active, Inactive)."New value: +"Entity status displayed in the Sunbiz result."

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.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context: it reveals the synchronous network execution via a specific Apify Actor, the billing side effect (creates a billed Actor run and dataset), the APIFY_TOKEN authentication requirement, and latency/limits (10-30 seconds typical, 120s timeout). These go far beyond the annotations and are critical for an agent to set expectations and avoid surprises.

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 description is structured with clear headers and front-loads the core purpose in the first sentence. Each subsequent section (Behavioral Transparency, Usage Guidelines) adds distinct, non-redundant information. No sentence is wasted, and the length is justified by the tool's complexity (network call, billing, auth, multiple usage scenarios).

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?

The tool has an output schema, so return values are documented elsewhere. The description covers execution model, side effects, authentication, latency, and usage exclusions. For a network-calling tool with billing implications, this is complete. An agent has everything needed to decide whether to call it, prepare credentials, and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond what the schema already provides. For example, max_results, search_query, and include_details are each fully described in the input schema. The description's mention of include_details in the latency context is contextual, not parameter semantics, so a 3 is appropriate.

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 states a specific verb ('Search'), a specific resource (Florida Division of Corporations Sunbiz business registry), and lists the returned fields (entity name, document number, status, entity type). It clearly distinguishes this from sibling tools by naming the exact state and registry. The purpose is unambiguous and immediately actionable.

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?

The description provides an explicit 'When to use' and 'When NOT to use' section, naming specific alternatives (florida_officer_search, us_business_entity_search, alabama_business_search) and the exact conditions under which each should be chosen. This gives an agent complete routing guidance with no inference required.

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