---
title: "Autoryzacja"
source: https://docs.senuto.com/authorization
api: POST /api/users/token
---

# Autoryzacja

Każde żądanie do API Senuto musi być uwierzytelnione **tokenem Bearer (JWT)** w nagłówku `Authorization`. Ta strona opisuje cały przepływ: od wymagań konta, przez pozyskanie tokenu, po obsługę błędów autoryzacji.

## Czego potrzebujesz

1. **Konta Senuto** — token jest powiązany z Twoim użytkownikiem i jego planem.
2. **Dostępu do API** w planie konta. Bez niego bezpośrednie wywołania API kończą się statusem `403` z pustą treścią. Jeśli Twój plan nie obejmuje dostępu do API, dokupisz go jako dodatek — [Dostęp do API](/access).

## Pozyskanie tokenu

Token uzyskasz, logując się adresem e‑mail i hasłem konta Senuto:

```
POST https://api.senuto.com/api/users/token
```

**cURL**

```bash
curl --location --request POST 'https://api.senuto.com/api/users/token' \
  --header 'Content-Type: application/json' \
  --data-raw '{ "email": "twoj@email.com", "password": "TWOJE_HASŁO" }'
```

**JSON (body)**

```json filename="ciało żądania"
{
  "email": "twoj@email.com",
  "password": "TWOJE_HASŁO"
}
```

Token wygenerujesz też bez wywoływania tego endpointu: panel Senuto, [Ustawienia konta → Integracje](https://app.senuto.com/user/integrations), kafelek **API**.

Nie chcesz używać terminala? Zaloguj się poniżej — token trafi prosto do przeglądarki i zostanie zapamiętany w playgroundzie na stronach endpointów:

### Odpowiedź

W polu `data.token` dostajesz JWT; pozostałe pola opisują konto:

```ts
type TokenResponse = {
success: true;
data: {
  /** Token JWT — przekazuj w nagłówku `Authorization: Bearer <token>` */
  token: string;
  /** ID Twojego użytkownika */
  id: number;
  email: string;
  /** Język konta, np. "pl-PL" */
  lang: string;
  /** Waluta konta, np. "PLN" */
  currency: string;
  currency_ratio: number;
  country_id: number;
};
}
export default TokenResponse
```

> **Ostrzeżenie:**
> **Token jest ważny 31 dni.** Nie ma osobnego endpointu odświeżania — po wygaśnięciu (`Token expired`) po prostu pobierz nowy token tym samym żądaniem. Traktuj token jak hasło: nie umieszczaj go w repozytorium ani w kodzie frontendowym; trzymaj w zmiennej środowiskowej lub sejfie sekretów.

## Użycie tokenu

Do **każdego** żądania dodaj nagłówek `Authorization`, a przy `POST` także `Content-Type: application/json`:

```
Authorization: Bearer <TWÓJ_TOKEN>
Content-Type: application/json
```

Szybki test poprawności tokenu — endpoint zwracający dane zalogowanego użytkownika:

```bash
curl --location 'https://api.senuto.com/api/users/whoami' \
  --header 'Authorization: Bearer $YOUR_TOKEN_HERE'
```

```json filename="odpowiedź"
{ "success": true, "data": { "email": "twoj@email.com" } }
```

## Błędy autoryzacji

Klasycznego `401` to API nie zwraca w żadnym z tych przypadków. Status zależy od tego, na którym
etapie odpadło żądanie.

| Sytuacja                                                           | Status                         | Treść odpowiedzi                              |
| ------------------------------------------------------------------ | ------------------------------ | --------------------------------------------- |
| Błąd logowania na `POST /api/users/token`                          | `418`                          | koperta błędu z `data.error.type` i `message` |
| Zwykły endpoint, token nieważny albo brak nagłówka `Authorization` | `302`, po przekierowaniu `404` | `{"success": false, "message": ""}`           |
| Konto bez aktywnego planu albo bez dodatku API                     | `403`                          | `{"success": false, "message": ""}`           |

### `418` — błędy logowania

Czytelny komunikat dostajesz wyłącznie z `POST /api/users/token`. Rozpoznawaj go po `data.error.message`.

| Komunikat                                      | Kiedy występuje                                    | Co zrobić                                |
| ---------------------------------------------- | -------------------------------------------------- | ---------------------------------------- |
| `Invalid username or password`                 | Błędny e‑mail lub hasło                            | Sprawdź dane logowania                   |
| `Token expired`                                | Wysłano tam token, którego nie da się zweryfikować | Loguj się e‑mailem i hasłem, nie tokenem |
| `Email isnt confrimed` _(pisownia oryginalna)_ | Konto z niepotwierdzonym adresem e‑mail            | Potwierdź e‑mail w panelu Senuto         |

```json filename="przykład — błędne dane logowania (HTTP 418)"
{
  "success": false,
  "data": {
    "error": { "type": "unauthorized", "message": "Invalid username or password" }
  }
}
```

### `302` → `404` — nieważny token na zwykłym endpoincie

> **Błąd:**
> Token po terminie ważności, token uszkodzony i całkowity brak nagłówka `Authorization` dają ten sam
> wynik: `302` z nagłówkiem `Location` na `/api/<moduł>/users/login`, a pod tym adresem
> `404 {"success": false, "message": ""}`.

Który z tych dwóch statusów zobaczysz, zależy od klienta HTTP. `curl -L`, `requests` i `axios` podążają
za przekierowaniem i raportują końcowe `404`. Postman z wyłączonym podążaniem za przekierowaniami
zatrzyma się na `302`. Oba znaczą to samo i jedno i drugie naprawia świeży token.

Jeśli integracja działała miesiąc i nagle „wszystkie endpointy zniknęły", to wygasł token, a nie zmieniło
się API (patrz [Błędy → status `404`](/types/errors)).

### `403` — konto bez dostępu do API

Token jest ważny, ale konto nie ma aktywnego planu albo dodatku Dostęp do API. Treść odpowiedzi jest
pusta (`{"success": false, "message": ""}`), więc rozpoznajesz ten przypadek po samym statusie.
Co dokupić: [Dostęp do API](/access).

## Co dalej

- [Pierwsze kroki](/get-started) — pierwsze zapytanie krok po kroku.
- [Analiza widoczności](/modules/visibility_analysis), [Monitoring](/modules/rank_tracker), [Baza słów kluczowych](/modules/keywords_analysis) — listy endpointów z interaktywnym playgroundem (token wklejasz w pole **API token** na stronie endpointu).
- [Błędy](/types/errors) — pełna koperta błędów i status `418`.