invalid-api-key

HTTP 401. Your request did not carry a key we could resolve to an API connection.

Code
{
  "type": "https://developers.supliful.com/errors/invalid-api-key",
  "title": "Invalid API key",
  "status": 401,
  "detail": "Present a valid API key as `Authorization: Bearer <key>`.",
  "instance": "/v1/me"
}

The response also carries WWW-Authenticate: Bearer realm="Supliful Public API".

Why you can't tell which cause it was

This one status covers four different situations:

• No key was sent, or the Authorization header used a scheme other than Bearer.
• The key is unknown, has been revoked, or has expired.
• The key exists but carries no connection — it was issued outside the normal flow.
• The key resolves to a connection that has been removed, or that belongs to a different account.

We deliberately do not tell them apart. Distinguishing "this key doesn't exist" from "this key exists but can't reach that connection" would let anyone confirm which keys are real by watching which error comes back. The trade is that a genuine misconfiguration looks identical to a bad credential, which is why the checklist below is worth working through in order.

How to fix it

1. Check the header. Authorization: Bearer <key> is the documented form. x-api-key: <key> also works, and is what most partner tooling sends by default. Anything else — Basic, a bare token with no scheme, a Bearer with no value — is treated as no key at all.
2. Check for whitespace. Keys are trimmed, but a newline pasted into a config file or an environment variable set with quotes included is a common cause.
3. Check the key is still enabled. Rotating a connection's key disables the previous one immediately. If a deploy is still running with the old value, it will get this error while a newer instance succeeds.
4. Confirm the connection still exists. If the API connection was removed in Supliful, its keys stop resolving even though they were never explicitly revoked.
5. Verify with /v1/me. It has no side effects and returns the connection a key acts as. If GET /v1/me succeeds and your own call does not, the problem is in that request rather than in the credential.

If all five check out, ask us at help@supliful.com and quote the instance path and the approximate time of the request — the cause is recorded on our side even though the response does not name it.

What not to do

Do not retry this error automatically. Nothing about it is transient: the same key will fail the same way until something changes in your configuration or in Supliful. Retrying will consume your rate limit and eventually produce rate-limit-exceeded on top of it.