Find Every Florida Entity Linked to a Person or Agent

Due-diligence analysts, journalists, and registered-agent services often need every business tied to one individual. The Sunbiz Daily API exposes officer, owner, partner, and registered-agent names as filters across all three record types. Search a person by full name — the API matches each word in any order — and add include=parties to get the matched people back in the same response.

Search corporate filings by officer or agent

On /api/v2/filings/, officer_name matches any of a filing's officers and registered_agent_name matches its registered agent. Pass a full name; the match is case-insensitive and order-independent (see below).

# Every corporation/LLC with an officer named "John Smith"
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/filings/?officer_name=John%20Smith"

# Every entity represented by a given registered agent.
# Word order and spacing don't matter — "corporation system" finds
# the agent Florida stores as "C T CORPORATION SYSTEM".
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/filings/?registered_agent_name=C%20T%20CORPORATION"

Why full-name search works in any order

Florida stores party names verbatim from its fixed-width data files, in one field and surname-first. A person record looks like this (the spaces are real, padding each column to a fixed width):

"officers": [
  { "position": 1, "name": "SMITH               MONTY         D", ... },
  { "position": 2, "name": "STONE               BRYAN", ... }
]

Because of that, the literal string "john smith" never appears in the data. So each name filter splits your value into words and requires every word to appear, in any order — officer_name=John%20Smith matches the stored "SMITH … JOHN" because both john and smith are present. Search by first name, surname, or the full name — whichever you have.

A comma separates independent names and ORs them, so you can trace several people at once:

# word-AND within a name, OR across comma-separated names
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/filings/?officer_name=John%20Smith,Maria%20Lopez"

Get the people back with `include=parties`

By default a list response carries only the entity and its location, not the people. Add include=parties and each row gains its officers (or owners / partners) and registered_agent inline — so one paged list request returns both the matched businesses and the people on them, with no per-row detail call.

curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/filings/?officer_name=Bryan%20Stone&include=parties"

{
  "filings": [
    {
      "corporation_number": "L26000301424",
      "corporation_name": "THE SALTY PHOTO CO LLC",
      "city": "FORT PIERCE", "state": "", "zip": "34951",
      "officers": [
        { "position": 1, "name": "JESSICA PROVERB STONE", "title": "MGMR", ... },
        { "position": 2, "name": "STONE               BRYAN", "title": "MGMR", ... }
      ],
      "registered_agent": { "name": "JESSICA PROVERB STONE", ... }
    }
  ],
  "pagination": { "total": 1, "page": 1, "per_page": 25, "total_pages": 1, ... }
}

Without include=parties the officers/owners/partners and registered_agent fields are null, keeping the default payload small. Request parties when you are tracing people; omit it when you only need the list of entities. The single-record detail endpoint still exists for fetching one filing in full.

Owners and partners work the same way

Fictitious names and partnerships carry their own people. Use owner_name on /api/v2/fictitious-names/ and partner_name (or registered_agent_name) on /api/v2/partnerships/ — same full-name, any-order matching, same include=parties.

# DBA registrations owned by "Maria Lopez", owners inline
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/fictitious-names/?owner_name=Maria%20Lopez&include=parties"

# Partnerships with a partner named "Michael Stone", partners inline
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/partnerships/?partner_name=Michael%20Stone&include=parties"

To build a complete picture of one person, query all three resources and merge the results.

The people filters at a glance

Resource	People filters
`/api/v2/filings/`	`officer_name`, `registered_agent_name`
`/api/v2/fictitious-names/`	`owner_name`
`/api/v2/partnerships/`	`partner_name`, `registered_agent_name`

Within one name the words are ANDed (any order); a comma separates independent names and ORs them. All of these combine with the shared city, state, zip, and date filters using AND logic, and with include=parties — so you can scope a name to a single county or time window and still get the people inline. (Fictitious names have no registered agent, so that resource offers owner_name only.)

Each word is still a substring

Every word in a name filter is matched as a substring, so a single common word casts a wide net: partner_name=stone also returns MILLSTONE, STONELAKE, and BLACKSTONE. Searching a full name tightens this dramatically — adding a given name to a surname requires both words to be present — but it is still substring matching, not exact matching. When precision matters, request include=parties and confirm the returned name before treating a row as a hit.

Big result sets: the 10,000-row ceiling

A common surname like smith matches a huge slice of the registry. The searches themselves are fast and return results directly, but a name that broad runs into a reachability ceiling you need to design around.

Only the first 10,000 rows are reachable. A list response caps the reported count: when there are more than 10,000 matches it returns "total": 10000 with "total_capped": true (and total_pages capped at 100), so paging stops at the 10,000th row. The true match count is far larger. Narrow with city, state, zip, or a date window — or use a full name instead of a lone surname — to bring a broad search fully within reach.
Occasionally a search is offloaded to a background job. If a particular query is too heavy to finish on the spot, the endpoint returns 202 Accepted with a job_id and a poll_url instead of results. Poll GET /api/v2/jobs/{job_id}/ until its status is done, then page the results with the usual page/per_page parameters (and include=parties if you set it). The job reports the exact total but still materializes only the first 10,000 rows ("truncated": true). It is worth handling a 202 even though most searches return 200 directly; offloaded searches also require the longest word of each name to be at least 3 characters, or the job is rejected with 422.

# Broad: returns 200, but total is capped — "total_capped": true, only 10,000 rows reachable
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/filings/?officer_name=smith"

# Scoped: a smaller, fully reachable result set
curl -H "X-API-Key: sb_your_key_here" \
  "https://sunbizdaily.com/api/v2/filings/?officer_name=smith&city=MIAMI&period=30d"

See the API documentation for the full background-job lifecycle, the 3-character minimum, and result expiry.

A note on privacy

Florida business filings are public record, but a business owner who used a home address can request a privacy takedown. Those filings are withheld from people searches entirely, and on the detail endpoint their people, registered agent, and mailing address are hidden with the principal address generalized to city level. Build your tooling to tolerate people and addresses being absent on a minority of records.

Next steps

Create a free key on your API Keys dashboard, then see the API documentation for every field returned on each resource.