Apify Public Data & Leads

Alabama Business Entity Registry Search

alabama_business_search

Read-only

Search Alabama official business registry by company name to verify LLC or corporation status, get entity ID, type, and location, and build targeted lead lists.

Instructions

Search official Alabama Secretary of State business-entity records by company name, returning entity ID, legal name, entity type, registry status, and location.

Behavioral Transparency:

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

Usage Guidelines:

When to use: Use when verifying an Alabama-registered LLC or corporation, checking entity status, or building a lead list of Alabama businesses by name.
When NOT to use: Do not use for Florida, California, or nationwide multi-state lookups, for contractor licensing, or for company officers/registered-agent name searches.
Named alternatives: Use 'us_business_entity_search' for a combined Florida/Alabama/Iowa/Wisconsin lookup, 'florida_new_filings_search' for Florida entities, or 'california_contractor_license_search'/'us_contractor_license_search' for contractor licences.

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 Alabama business name to search (e.g. 'SMITH' or 'Smith Services LLC').
`include_details`	No	When true, opens each result's detail page to add formation date, registered agent, and registered/principal addresses. 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.

Changed18 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 Alabama business-entity records matching the search query."
```
- addedOutput schema / properties / results / items / properties / entity_id / title
```
Added value: +"Entity ID"
```
- addedOutput schema / properties / results / items / properties / entity_name / title
```
Added value: +"Legal entity name"
```
- addedOutput schema / properties / results / items / properties / entity_type / title
```
Added value: +"Entity type"
```
- changedOutput schema / properties / results / items / properties / formation_date / description
```
Previous value: -"Date the entity was formed, from the detail record (requires include_details)."New value: +"Date the entity was formed, from the state's detail record."
```
- addedOutput schema / properties / results / items / properties / formation_date / title
```
Added value: +"Formation date"
```
- addedOutput schema / properties / results / items / properties / location / title
```
Added value: +"Location"
```
- changedOutput schema / properties / results / items / properties / principal_address / description
```
Previous value: -"Principal place of business, where the state records one (requires include_details)."New value: +"Principal place of business, where the state records one."
```
- 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 registered agent (requires include_details)."New value: +"Name of the entity's registered agent."
```
- addedOutput schema / properties / results / items / properties / registered_agent / title
```
Added value: +"Registered agent"
```
- changedOutput schema / properties / results / items / properties / status / description
```
Previous value: -"Current registry status when present (e.g. Exists, Dissolved, Revoked)."New value: +"Current registry status when present."
```
- 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?

The description adds substantial behavior beyond annotations: synchronous network execution via a specific Apify Actor, billed run/dataset side effects, APIFY_TOKEN requirement, typical latency, detail-page impact, and a 120-second timeout. This goes well beyond the minimal readOnlyHint context.

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 first sentence delivers a complete purpose statement, then the description is cleanly divided into Behavioral Transparency and Usage Guidelines sections. Every bullet adds operational or selection value with no 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?

The tool has an output schema and rich annotations, and the description still adds all essential operational context: authentication, side effects, latency, timeout, and explicit routing to alternatives. Nothing needed for correct invocation is missing.

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 coverage is 100% and each parameter already has a clear description, so the description does not need to compensate. The main text adds some cross-referencing context around max_results billing and include_details latency, but it does not materially increase parameter meaning beyond the schema.

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 uses a specific verb and resource: 'Search official Alabama Secretary of State business-entity records by company name,' and lists the returned fields. The Alabama scope and mention of official registry records clearly distinguish it from sibling 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?

The description provides explicit when-to-use guidance, a when-NOT-to-use list, and named alternatives for Florida, multi-state, contractor-license, and officer searches. An agent can confidently select or reject this tool without opening schemas.

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