API keys authenticate your app, not a member. Use them on
restaurant and location Discovery routes. They are the only
credential those routes accept.
API keys are 40-character strings with a prefix that indicates how
they were issued:
fly_live_ keys are production keys; fly_test_ keys are staging/dev
keys. The environment binding is server-side: your key is scoped to
the DeveloperApp and environment it was minted under. Use the key you
received in your onboarding email for the environment you were
provisioned for.
Send the key in X-API-Key:
What API keys cover
From the kitchen - Discovery routes use the API key. Member-acting
routes use OAuth. The two do not substitute for each other.
Chef’s warning - API keys are server-side only. Every call
that carries an API key must originate from your backend, never
from a browser, mobile client, or any code shipped to users. Don’t
embed them in client-side bundles, public repos, screenshots, or
environment variables checked into source. A key visible in a
client is a key you have to assume is compromised. Treat them as
you would a password, and route Discovery calls through your own
backend rather than calling the API directly from the client.
If a key leaks
Contact Blackbird support to revoke and issue a new key. Old keys
stop working immediately on revocation.
Mixing environments
Don’t reuse a key across environments. Your fly_test_ staging key
authenticates against the staging API; your fly_live_ production key
authenticates against the production API. They’re issued separately and
aren’t substitutes for each other. 
