Authentication

FishSpeech Open API requests use bearer API keys. The API key identifies the account, permission scope, quota, and billing context for the request.

Authorization: Bearer FISHSPEECH_API_KEY

Create and manage API keys in your account:

/en/account?section=api

Request Rules

Every Open API request must include the Authorization header. JSON requests should also include Content-Type: application/json. Multipart endpoints should let your HTTP client set the multipart boundary.

curl https://fishaudio.org/api/open/v1/profile \
  -H "Authorization: Bearer FISHSPEECH_API_KEY"

Do not send API keys from browser JavaScript, mobile apps, public repos, logs, analytics events, or customer-visible error messages. Treat the API key like a password for your production account.

API Key Storage

Store the API key in a server-side secret manager or encrypted environment variable. Load it at process start and pass it only to the HTTP client that talks to FishSpeech. If you run background workers, give workers the same secret through your deployment platform rather than copying it into job payloads.

Rotate API keys when a team member leaves, when a build log may have exposed a secret, or when you move an integration from staging to production. After rotation, deploy the new API key first, verify traffic, then revoke the old API key.

Response And Error Handling

Authentication failures return JSON errors when the request reaches the API layer.

Log requestId from error responses. It lets support locate the exact request without asking you to share API keys or raw payloads.

Billing And Credits

Authentication itself does not consume credits. Authenticated media endpoints may reserve or consume credits depending on the endpoint. A valid API key therefore does not guarantee that a generation request will succeed; your application should separately handle balance and quota errors.