Przejdź do treści
DarhimLabs Developers

DarhimLabs API

Handle rate limits gracefully

Retry z Retry-After, jitterem i metrykami wykorzystania limitu.

Handle rate limits gracefully

Retry z Retry-After, jitterem i metrykami wykorzystania limitu.

Kiedy tego uzyc

Uzyj tego przepisu, gdy chcesz: Zareagowac na 429 bez thundering herd i bez utraty pracy w kolejce.

Endpoint referencyjny: Any API endpoint.

Implementacja

Node.js

import { DarhimLabs } from "@darhimlabs/node";

const client = new DarhimLabs(process.env.DARHIMLABS_API_KEY!);
if (error.status === 429) await sleep((error.retryAfter ?? 5) * 1000 + Math.random() * 500);

Python

import os
from darhimlabs import DarhimLabs

client = DarhimLabs(api_key=os.environ["DARHIMLABS_API_KEY"])
if exc.status == 429:
    time.sleep((exc.retry_after or 5) + random.random())

PHP

<?php

$client = new DarhimLabs\Client(["api_key" => $_ENV["DARHIMLABS_API_KEY"]]);
if ($e->status === 429) { usleep((($e->retryAfter ?? 5) * 1000 + random_int(0, 500)) * 1000); }

Ruby

client = DarhimLabs::Client.new(api_key: ENV["DARHIMLABS_API_KEY"])
sleep((error.retry_after || 5) + rand)

Test it

  1. Wykonaj request w sandboxie z kluczem dl_test_....
  2. Sprawdz X-Request-ID w odpowiedzi.
  3. Dla webhookow uzyj Webhook Playground, zeby zobaczyc payload live.

Common pitfalls

  • Nie retryuj rowno co sekunde z wielu workerow. Dodaj jitter.
  • Loguj request_id i event_id, zeby support mogl odtworzyc problem.
  • Dla mutacji dodawaj Idempotency-Key, szczegolnie jesli request moze byc retryowany.

Production checklist

  • Dodaj retry z exponential backoff i jitterem.
  • Ogranicz scopes API key do minimalnego zestawu.
  • Monitoruj rate limit headers i latency P95.
  • Przetestuj bledy 401, 409, 422 i 429.

Related