API authentication

Authenticate the Feedjolt API with API keys sent as a Bearer token in the Authorization header. Create, scope, and revoke keys - server-to-server only.

The API uses API keys. Each request must include Authorization: Bearer <key>.

Creating a key

Dashboard -> Settings -> API keys -> New key.

You'll set:

Name - for your sanity. production-zapier, local-dev-marc. Not "key", "test", "asdf".
Scopes - what the key can do (stored as a JSON array on the key).

The full key is shown once when generated. Save it; we only store a hash. Lost key = make a new one.

Format

fjk_<random>

The fjk_ prefix is intentional:

Easy to spot in your logs (and our git-leak detection).
Easy to write a regex / pre-commit hook against.
Lets you tell at a glance "this is a Feedjolt key, not a Stripe key".

Treat the full key as a secret. Don't put keys in: client-side code, mobile apps, public repos, customer support tickets, screenshots.

Sending the key

Authorization: Bearer fjk_abc123...

Examples:

curl -H "Authorization: Bearer $FEEDJOLT_KEY" \
     "https://api.feedjolt.com/api/v1/boards/feature-requests/posts"

fetch("https://api.feedjolt.com/api/v1/boards/feature-requests/posts", {
  headers: { Authorization: `Bearer ${process.env.FEEDJOLT_KEY}` }
});

import os, httpx
r = httpx.get(
    "https://api.feedjolt.com/api/v1/boards/feature-requests/posts",
    headers={"Authorization": f"Bearer {os.environ['FEEDJOLT_KEY']}"}
)

Keys carry a list of scopes. The exact scope strings and the per-endpoint scope checks are documented in the OpenAPI reference under each endpoint's "security" section - that's the source of truth.

When picking scopes, default to read-only and expand only as needed. Missing-scope calls return 403.

Revoking

Settings -> API keys -> Revoke. Immediate.

If a key leaks:

Revoke it.
Generate a new key.
Update your secret store.
Redeploy.
Consider rotating any data that may have been read.

Server-to-server only

There is no client-side API key flow. Keys must stay server-side. Browser calls should go through your backend.

For unauthenticated client-side access (read-only public data), use the widget or the public portal's standard URLs - they're publicly indexed and have no auth requirement.