---
title: "Invalid API key"
description: "Which Fillo credential a request needs, where each one belongs, and how to debug a 401."
group: "Reference"
order: 2
type: "troubleshooting"
parent: "troubleshooting"
keywords:
  - "API key"
  - "401"
  - "fsk"
  - "pk"
  - "fcli"
  - "credentials"
updated: "2026-07-14"
---

Fillo credentials aren't interchangeable. Check the prefix before you rotate anything.

| Prefix | Purpose | Where it may live |
| --- | --- | --- |
| `pk_` | Resolve and, when policy permits, stage code-defined forms | Browser or server |
| `fsk_` | Read and manage workspace data through the Management API | Server only |
| `fcli_` | CLI, MCP login, and Zapier workspace access | Private local or server storage |
| `is_` | Sign respondent identity context | Server only |

Webhook signing secrets and storage credentials are separate secrets — they can't authenticate an API request.

## Published forms don't need a key

Loading and submitting a published form uses its form ID or hosted slug. If that request fails, removing an unnecessary authorization header can help more than creating another key.

## Diagnose a `401`

1. Confirm the request is going to the intended Fillo API origin.
2. Check that the complete value, prefix included, reached the process without quotes or trailing whitespace.
3. Use the authorization format required by that API or SDK, normally `Authorization: Bearer <credential>` for private endpoints.
4. Verify the credential belongs to the workspace that owns the requested resource.
5. Check whether the key or token was revoked or replaced.

Don't log the full value. Log the credential type and a non-secret request identifier instead.

## Distinguish authorization from lookup failures

A valid credential can still get a `403` when its credential class can't perform the operation. Management endpoints can return `404` for inaccessible form IDs so one workspace can't discover another workspace's records. And code sync can reject a valid `pk_` key when the origin or the workspace sync policy blocks mutation.

## Rotate safely

Create or reveal the replacement in the dashboard, update your secret store, redeploy callers, and verify them before revoking the old credential. Browser deployments using a `pk_` key need a normal client rebuild. Never ship an `fsk_`, `fcli_`, identity secret, or webhook secret in a browser bundle.

## Related

- [Security](/docs/security): Place each credential on the correct trust boundary.
- [Blocked by CORS policy](/docs/troubleshooting/cors-error): Fix an origin rejection without exposing a private key.
- [MCP server](/docs/mcp): See how the MCP process discovers local Fillo credentials.