Find Every Florida Entity Linked to a Person or Agent

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).

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):

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.

Commas are part of the name, so you can paste Sunbiz's own surname-first rendering — officer_name=Smith,%20John finds that one person, and an agent name like VENCO MANAGEMENT, INC. works as typed. To trace several people at once, separate independent names with a pipe (|, URL-encoded as %7C):

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.

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.

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

The people filters at a glance

Within one name the words are ANDed (any order) and commas are part of the name; a pipe (|) separates independent names and ORs them. Each word matches as a substring unless you pass name_match=whole_word (see below). 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 a substring — unless you ask for whole words

By default 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 each word is still a substring, so officer_name=John%20Smith also matches an officer named GOLDSMITH JOHNNIE.

Add name_match=whole_word to require each word to match a whole word in the stored name. john then no longer matches JOHNNIE and smith no longer matches GOLDSMITH, while everything else stays the same: word order still doesn't matter, commas are still part of the name, and | still ORs independent names. For a normal name it runs in the same cost class as the default.

Keep the default when you want recall — nicknames, middle initials, and inconsistent hyphenation all survive substring matching — and switch to whole_word when a common surname is drowning your results. Only substring and whole_word are accepted; any other value returns 422. Neither mode is exact matching, so when precision really matters, request include=parties and confirm the returned name before treating a row as a hit.

Three details worth knowing about whole_word:

• Digits and underscores count as word characters. So whole-word smith matches SMITH but not SMITH2. (This differs from business-name keyword matching, where a digit is treated as a boundary.)
• A word with no letters or digits at its edges falls back to substring. A token like #1 has nothing for a word boundary to anchor on, so it is matched as a substring rather than matching nothing at all.
• A name whose every word is under 3 characters falls back to substring too. officer_name=al&name_match=whole_word behaves exactly like the default. Only one word of the name needs to reach 3 characters for whole-word matching to apply to all of them — smith p is matched whole-word on both words.

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). A job that matches more than 10,000 rows materializes only the first 10,000 and reports "truncated": true, with total held at 10,000 and "total_capped": true — read it as “10,000 or more”. Narrow the filter if you need an exact count. 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.

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.