Florida Business API

Authentication

API key format, header conventions, and rotation strategy for Florida Business API.

Florida Business API uses API key authentication. Every request to /api/v1/* requires a key.

Florida Business API is an independent data platform and is not affiliated with Sunbiz.org, the Florida Department of State, or the Florida Division of Corporations.

Getting a Key

Create an account and provision a key from the Account page. Keys are issued instantly and the raw key value is shown once at creation time — copy it into your secret store before you close the dialog. We only store an HMAC-SHA256 hash and cannot retrieve it for you.

Live keys count against your billing tier. Test keys (fbapi_test_...) hit the same endpoints with reduced quota and are safe to commit into CI logs.

Header Format

Send your API key in either header. Authorization: Bearer is the preferred convention (matches Stripe, GitHub, Anthropic) and is what we use in every example.

Authorization: Bearer fbapi_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The X-API-Key fallback exists for clients that strip the Authorization header (some browser extensions, naive proxies):

X-API-Key: fbapi_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Querystring auth is not supported. Passing the key as ?api_key=... will not authenticate the request and risks leaking the key into server logs, browser history, and HTTP referrers. Always use a header.

If both headers are present and they disagree, the request is rejected as 401 unauthorized — disagreement signals a credential-confusion attack and we will not silently pick one.

Key Format

Keys follow the pattern fbapi_{live|test}_{32-char-base62}.

PrefixEnvironmentNotes
fbapi_live_ProductionCounts against your paid tier's monthly quota.
fbapi_test_TestSame endpoints, reduced quota, safe to commit to CI logs.

Quick Test

curl -i -H "Authorization: Bearer fbapi_test_..." \
  "https://api.floridabusinessapi.com/v1/entities/search?name=ACME&limit=1"

A successful response returns 200 with the standard { data, pagination, meta } envelope plus X-RateLimit-Remaining / X-RateLimit-Reset headers (see Rate Limits).

401 Envelope

Every authentication failure returns the same shape — we do not distinguish between "missing key", "revoked key", and "wrong key" so attackers cannot use the API as a key-validity oracle.

HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid API key.",
    "request_id": "req_1234567890abcdef12345"
  }
}

If you see unauthorized repeatedly, double-check that:

  1. The header is Authorization: Bearer <key> (case-insensitive Bearer, single space).
  2. You are not stripping the fbapi_live_ / fbapi_test_ prefix.
  3. You have not revoked the key from the Account page.
  4. The client / workspace status is active (a suspended workspace returns 401 for every key it owns).

Storage

Keys are stored as HMAC-SHA256 hashes. The raw key is returned exactly once at creation — store it securely; we cannot retrieve it for you.

Rotation

Create the new key first, deploy it, then revoke the old one — both can be active in parallel for as long as you need to roll out the change. There is no quota penalty for keeping multiple live keys; each is metered against the same client-level monthly quota.

Revoked keys return 401 unauthorized immediately on the next request — we enforce status='active' AND revokedAt IS NULL at the SQL WHERE level, so there is no cache window that can serve a stale answer.

On this page