Webhook event catch-up po downtime

Odtworzenie przegapionych eventow po awarii endpointu klienta.

Kiedy tego uzyc

Uzyj tego przepisu, gdy chcesz: Znalezc failed deliveries i ponowic je w kontrolowany sposob.

Endpoint referencyjny: GET /webhooks/deliveries + POST /webhooks/deliveries/{id}/replay.

Implementacja

Node.js

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

const client = new DarhimLabs(process.env.DARHIMLABS_API_KEY!);
const failed = await client.webhookEndpoints.deliveries.list({ status: 'failed' });

Python

import os
from darhimlabs import DarhimLabs

client = DarhimLabs(api_key=os.environ["DARHIMLABS_API_KEY"])
failed = client.webhook_endpoints.deliveries.list(status='failed')

PHP

<?php

$client = new DarhimLabs\Client(["api_key" => $_ENV["DARHIMLABS_API_KEY"]]);
$failed = $client->webhookEndpoints->deliveries->list(['status' => 'failed']);

Ruby

client = DarhimLabs::Client.new(api_key: ENV["DARHIMLABS_API_KEY"])
failed = client.webhook_endpoints.deliveries.list(status: 'failed')

Test it

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

Common pitfalls

Replay moze dostarczyc event po czasie. Handler musi byc idempotentny.
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.