Аутентификация API
StatusRadar не использует единую схему аутентификации. Разные поверхности API используют разные учётные данные, потому что к ним обращаются разные клиенты (ваш код, ваши серверы, браузер). Это руководство описывает все три схемы, где получить каждый токен и как его отправлять.
Схемы аутентификации вкратце
| Поверхность | Эндпоинты | Схема | Куда отправлять | Хост |
|---|---|---|---|---|
| User API + Probe API | /v1/monitors, /v1/incidents, /v1/status-pages, /v1/probe/* |
Bearer-токен | Заголовок Authorization: Bearer <token> |
api.statusradar.dev |
| Приём OTLP | /v1/traces, /v1/logs, /v1/metrics |
Токен приложения | Заголовок X-App-Token: <token> |
otlp.statusradar.dev |
| Приём RUM | /v1/ingest |
API-ключ | Параметр запроса api_key |
rum.statusradar.dev |
Важно отправлять правильные учётные данные на правильный хост: токен OTLP-приложения не пройдёт аутентификацию в User API, а Bearer-токен не принимается коллектором RUM.
Публичные эндпоинты
GET /api/status/{slug}иGET /api/monitors/{id}/uptimeне требуют аутентификации.
1. User API и Probe API — Authorization: Bearer <token>
User API (управление мониторами, инцидентами, status-страницами) и Probe API (распределённое выполнение проверок) аутентифицируются Bearer-токеном в заголовке Authorization.
Authorization: Bearer YOUR_TOKEN
Где получить токен
- Пользовательский API-токен — Dashboard → Settings → API (
/dashboard/settings/api). Нажмите Generate New Token, задайте имя и скопируйте токен. Токен показывается только один раз; если он потерян, сгенерируйте новый. Отозвать токен можно на той же странице. - Probe-токен — выдаётся StatusRadar при провижининге probe-сервера. Probe-токены управляются платформой, а не самостоятельно.
Примеры curl
Список ваших мониторов (User API):
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
https://api.statusradar.dev/v1/monitors
Создание монитора (User API):
curl -X POST https://api.statusradar.dev/v1/monitors \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"My Website","target":"https://example.com","type":"http"}'
Получение ожидающих проверок (Probe API):
curl -H "Authorization: Bearer YOUR_PROBE_TOKEN" \
https://api.statusradar.dev/v1/probe/get-checks
Отправка результата проверки (Probe API):
curl -X POST https://api.statusradar.dev/v1/probe/check-result \
-H "Authorization: Bearer YOUR_PROBE_TOKEN" \
-H "Content-Type: application/json" \
-d '{"monitor_id":123,"status":"up","response_time_ms":142}'
Probe API также доступен на основном домене (
statusradar.dev/v1/...). Поддоменapi.предпочтителен для API-клиентов.
2. Приём OTLP — X-App-Token: <token>
Приём traces, logs и metrics OpenTelemetry использует токен на каждое приложение, отправляемый в заголовке X-App-Token, на хост otlp.statusradar.dev. Это учётные данные, которые использует ваш бэкенд OTLP-экспортёр (или StatusRadar SDK / telemetry-agent).
X-App-Token: YOUR_APP_TOKEN
Где получить токен
Dashboard → Observability (/dashboard/observability). Создайте или откройте приложение observability; его токен приложения отображается на странице настроек приложения (/dashboard/observability/{id}/settings). Каждое приложение имеет собственный токен и опциональный whitelist доменов для CORS.
Примеры curl
Отправка traces:
curl -X POST https://otlp.statusradar.dev/v1/traces \
-H "X-App-Token: YOUR_APP_TOKEN" \
-H "Content-Type: application/json" \
-d @traces.json
Отправка logs:
curl -X POST https://otlp.statusradar.dev/v1/logs \
-H "X-App-Token: YOUR_APP_TOKEN" \
-H "Content-Type: application/json" \
-d @logs.json
Отправка metrics:
curl -X POST https://otlp.statusradar.dev/v1/metrics \
-H "X-App-Token: YOUR_APP_TOKEN" \
-H "Content-Type: application/json" \
-d @metrics.json
Конфигурацию экспортёра см. в Обзор OTLP и OTLP SDK.
3. Приём RUM — параметр запроса api_key
Real User Monitoring работает в браузере, поэтому не может полагаться на приватный секрет в заголовке так, как это делает бэкенд. Браузерный SDK отправляет события на rum.statusradar.dev/v1/ingest с ключом приложения, передаваемым в параметре запроса api_key.
POST https://rum.statusradar.dev/v1/ingest?api_key=YOUR_RUM_KEY
В браузерном SDK это настраивается опцией apiKey; SDK передаёт его как параметр запроса api_key в каждом запросе.
Где получить ключ
Dashboard → Observability (/dashboard/observability). То же приложение observability предоставляет api_key, используемый браузерным SDK RUM. Поскольку ключ RUM поставляется в браузеры, защитите его с помощью whitelist доменов приложения (allow-list по Origin/CORS) в настройках приложения (/dashboard/observability/{id}/settings), а не относитесь к нему как к секрету.
Пример curl
curl -X POST "https://rum.statusradar.dev/v1/ingest?api_key=YOUR_RUM_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"pageload","url":"https://example.com/","duration_ms":820}'
Браузерный SDK
StatusRadarRUM.init({
apiKey: 'YOUR_RUM_KEY',
endpoint: 'https://rum.statusradar.dev/v1/ingest'
});
Полную настройку см. в Быстрый старт RUM.
Безопасность токенов
- Никогда не коммитьте токены в систему контроля версий. Загружайте их из переменных окружения или менеджера секретов.
- Используйте правильный токен для каждой поверхности. User/Probe Bearer-токен, токен OTLP-приложения и RUM api_key не взаимозаменяемы.
- Держите бэкенд-токены вне фронтенда. Токены User API, Probe и OTLP — это секреты, и они должны оставаться на стороне сервера. Только RUM
api_keyпредназначен для браузера, и его защита опирается на whitelist доменов. - Ротируйте и отзывайте. Периодически перевыпускайте пользовательские API-токены и отзывайте любой токен, который мог утечь. Токены/ключи приложений observability управляются на каждое приложение в дашборде.
# Load from environment, never hardcode
export STATUSRADAR_TOKEN="your-token"
curl -H "Authorization: Bearer $STATUSRADAR_TOKEN" \
https://api.statusradar.dev/v1/monitors
Ошибки аутентификации
Отсутствующие или недействительные учётные данные возвращают 401 Unauthorized:
{
"error": true,
"message": "Unauthorized",
"code": "unauthorized",
"status": 401
}
Типичные причины:
- Неверная схема для поверхности — например, отправка
Authorization: Bearerв OTLP (который ожидаетX-App-Token) или в RUM (который ожидаетapi_key). - Неверный хост — отправка запроса на
api.statusradar.dev, когда эндпоинт находится наotlp.statusradar.devилиrum.statusradar.dev. - Некорректный заголовок Bearer — отсутствует префикс
Bearerили есть лишние пробелы. - Отозванный токен — отозванные токены немедленно перестают работать; сгенерируйте новый.
# Inspect what credential is actually being sent
curl -v -H "Authorization: Bearer $STATUSRADAR_TOKEN" \
https://api.statusradar.dev/v1/monitors 2>&1 | grep -i 'authorization\|x-app-token'
Дальнейшие шаги
- Обзор API - структура API, базовый URL и соглашения
- Обзор OTLP - отправка traces, logs и metrics с
X-App-Token - Быстрый старт RUM - подключение браузерного SDK с вашим
api_key - Создание приложений Observability - получение токена OTLP и ключа RUM
- Домены Observability - привязка ключа RUM к вашим origin
- Схемы аутентификации вкратце
-
1. User API и Probe API — `Authorization: Bearer
` - Где получить токен
- Примеры curl
-
2. Приём OTLP — `X-App-Token:
` - Где получить токен
- Примеры curl
- 3. Приём RUM — параметр запроса `api_key`
- Где получить ключ
- Пример curl
- Браузерный SDK
- Безопасность токенов
- Ошибки аутентификации
- Дальнейшие шаги