Документація·Ідемпотентність
🔁

Ідемпотентність

Як хедер `Idempotency-Key` оберігає від подвійного списання при ретраях на нестабільних мережах.

Навіщо це

Мережі падають посеред запиту. Якщо ви робите POST /v1/activations і з'єднання обривається до отримання відповіді, ви не знаєте, чи активація була створена. Наївний retry може списати двічі.

Хедер Idempotency-Key вирішує це: надішліть той самий ключ на retry — отримаєте той самий результат.

Як використовувати

Згенеруйте UUID на логічну операцію, надсилайте його на кожному retry:

KEY=$(uuidgen)
curl -X POST https://api.eveses.com/v1/activations \
  -H "Authorization: Bearer $EVESES_API_KEY" \
  -H "Idempotency-Key: $KEY" \
  -d '{"country":"ua", "service":"telegram"}'

Повтор того ж запиту з тим самим Idempotency-Key повертає оригінальну відповідь — без другої активації, без другого списання.

TTL

Ключі зберігаються 24 години. Після цього слот звільняється і ключ можна використати як новий.

Де застосовується

Усі POST /v1/* ендпоінти що створюють або списують: активації, оренда, депозити, продовження. Read-ендпоінти (GET) вже ідемпотентні і ігнорують хедер.

Конфлікти

Якщо ви переуикористовуєте ключ із іншим body — API повертає 409 idempotency_conflict. Або тримайте body ідентичним на ретраях, або генеруйте новий ключ.

Поведінка SDK

Офіційні SDK автоматично генерують idempotency-keys для кожного create-виклику і переуикористовують їх на автоматичних retry. Можна перевизначити явним ключем.

← ПопередняSDKНаступна →OpenAPI та Postman