Authentication

Every /v1 request authenticates with a secret key in the Authorization header. The key identifies your application and selects the data environment.

curl https://api.feelconnect.dev/v1/accounts/get \
  -H "Authorization: Bearer fc_sk_test_4Kj9mQ2xP7cW1nR4tYb8sJd3fV6zL0aG" \
  -H "Content-Type: application/json" \
  -d '{"access_token":"fc_at_..."}'

Key types

Keys are created in Dashboard → API keys. FeelConnect stores only a SHA-256 hash of each secret, plus a display prefix and last four characters — a lost key cannot be recovered, only replaced.

Environment selection

The key is the environment. A fc_sk_test_ key can only see items created with test keys, and fc_sk_live_ only live items. Access tokens are bound to the application and environment that created them — using a test key with a live item's token returns item_not_found.

Response headers

Authentication failures

All failures use the standard error envelope with HTTP 401 or 403:

{
  "error": {
    "type": "authentication_error",
    "code": "invalid_api_key",
    "message": "This API key does not exist or was revoked.",
    "request_id": "req_2kD8fQx1mZ7cW4nY0bT3"
  }
}

Key rotation

• Create a second key in the dashboard — an application can hold multiple active keys.
• Deploy the new key to your servers.
• Revoke the old key. Revocation is immediate; in-flight requests with the old key fail with invalid_api_key.
• Access tokens are not affected by key rotation — they belong to the application, not the key.