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}.
| Prefix | Environment | Notes |
|---|---|---|
fbapi_live_ | Production | Counts against your paid tier's monthly quota. |
fbapi_test_ | Test | Same 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:
- The header is
Authorization: Bearer <key>(case-insensitiveBearer, single space). - You are not stripping the
fbapi_live_/fbapi_test_prefix. - You have not revoked the key from the Account page.
- The client / workspace status is
active(a suspended workspace returns401for 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.