Аутентификация

В каждый запрос добавляется заголовок:

Authorization: Api-Key dp_live_7f3a9c21.hV2nQpX8mK4rT7yLwZ0aB3cD6eF9gJ1kN5sU8vY2xA

Слово Api-Key нечувствительно к регистру.

Альтернативный вариант — если ваша библиотека своевольно обращается с заголовком Authorization (это частая ситуация в 1С):

X-Api-Key: dp_live_7f3a9c21.hV2nQpX8mK4rT7yLwZ0aB3cD6eF9gJ1kN5sU8vY2xA

Второй заголовок читается только если Authorization отсутствует, пуст или содержит другую схему (например Bearer).

Не отправляйте оба заголовка одновременно. Если Authorization: Api-Key присутствует, проверяется только он — даже если ключ в нём неверный, а в X-Api-Key лежит правильный. Результат: 401 при формально верном ключе. Это типичная ошибка при переключении между двумя вариантами: старый заголовок остался в настройках соединения. Выберите один способ.

Ошибки аутентификации

Все ответы 401 содержат заголовок WWW-Authenticate: Api-Key.

Ситуация	Ответ
Заголовок есть, ключа нет	{"detail": "Invalid API key header. No credentials provided."}
В ключе пробелы	{"detail": "Invalid API key header. Token contains spaces."}
Ключ неверный, отозван или просрочен	{"detail": "Invalid API key."}
Заголовка нет вообще	{"detail": "Authentication credentials were not provided."}

Обратите внимание: несуществующий, отозванный и просроченный ключ дают одинаковый ответ. Это сделано намеренно, чтобы нельзя было перебором выяснить, какие ключи существуют. Если интеграция внезапно перестала работать с этой ошибкой — проверьте в интерфейсе, не истёк ли срок и не отозван ли ключ.