Encoders & Utilities

Tester webhooków

Generuj unikalny URL, odbieraj dowolne żądania HTTP i sprawdzaj metodę, nagłówki, query i body na żywo.

Generates a new bin with a unique receiver URL. Solve the captcha to continue.

How it works

  • All HTTP methods are accepted (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS).
  • Text bodies are stored up to 10 KB; larger bodies are truncated. Binary bodies (images, files, octet-stream) are replaced with a 1 KB stub plus SHA-256 of the original.
  • A bin keeps the 10 most recent requests; older entries are dropped automatically (FIFO).
  • Bins live for 24 hours after their last activity. View opens, receive hits, all reset the timer.
  • Recognized signature headers (GitHub, Stripe, Slack, Shopify, Twilio) are highlighted, but never verified — we do not know your secret.

O tym narzędziu

Webhook Tester daje Ci jednoklikowy publiczny URL, który przechwytuje każde żądanie HTTP wysłane do niego — metodę, nagłówki, parametry query, body (tekst lub binarne), timestampy i source IP. URL pozostaje żywy przez 24 godziny; żądania strumieniują się do Twojej przeglądarki w czasie rzeczywistym przez Server-Sent Events, więc widzisz przychodzące hity w momencie, gdy lądują, bez pollingu. Każdy unikalny URL jest prywatny (128-bitowy losowy token w ścieżce), więc tylko ludzie, z którymi się dzielisz, mogą postować do niego.

Wszystko przechwycone jest pokazane obok siebie: raw request line, nagłówki, sparsowane query, body z autodetekcją JSON / XML / form-encoded / plain text. Nagłówki jak X-Hub-Signature, Stripe-Signature lub dowolna weryfikacja w stylu HMAC mogą być zinspekowane do debugowania schematów podpisywania. Możesz też skonfigurować odpowiedź — zmień kod statusu, dodaj nagłówki odpowiedzi lub wyślij body JSON — by zasymulować endpoint produkcyjny i potwierdzić, że Twój producer obsługuje non-2xx odpowiedzi poprawnie.

Kiedy używać tego narzędzia

  • Integracja z API third-party. Stripe, GitHub, Twilio, Slack — każdy z nich potrzebuje publicznego callback URL, by rozwijać się wobec niego; to narzędzie daje Ci jeden bez konfigurowania tuneli.
  • Debugowanie payloadów webhooków. Zobacz dokładne bajty, które produkuje sender, nagłówki i wszystko, przed napisaniem własnego konsumera.
  • Testowanie zachowania retry. Ustaw odpowiedź na 500 i potwierdź, że producer retry-uje; przełącz na 200 i potwierdź, że przestaje.
  • Reprodukcja problemu. Przechwyć failujący payload webhooka, potem odtwórz go z curl-equivalent do swojego lokalnego dev serwera.

O persistence i prywatności

Przechwycone żądania są przechowywane przez 24 godziny i potem usuwane. Sam URL pozostaje aktywny w tym oknie — dziel się ostrożnie, bo każdy, kto go ma, może postować cokolwiek. Dla wrażliwych integracji (produkcyjne webhooki płatności) użyj narzędzia tunelu-do-localhost (ngrok, cloudflared tunnel) — to trzyma payloady całkowicie na Twojej lokalnej maszynie. To narzędzie jest do development i testowania, nie do prawdziwego ruchu produkcyjnego.

Najczęstsze pytania

Jak długo mój webhook URL pozostaje aktywny?

24 godziny od utworzenia. Przechwycone żądania są trzymane w tym samym oknie i potem auto-usuwane. Jeśli potrzebujesz dłużej żyjącego URL, odtworzy go z tej samej strony (daje Ci świeży token) i zaktualizuj sendera. Dla stałych integracji hostuj mały endpoint sam lub użyj narzędzia tunelu, które celuje w Twój lokalny dev serwer.

Czy widzę przychodzące żądania w czasie rzeczywistym?

Tak — strona subskrybuje Server-Sent Events (SSE) z naszego backendu, więc każde nowe żądanie pojawia się w tabeli w miarę przybywania, typowo w milisekundy. Odśwież stronę w razie potrzeby; historia jest też persistowana po stronie serwera w oknie 24h, więc przeładowanie dostaje pełną listę.

Czy to bezpieczne dla produkcyjnych sekretów webhooka?

Nie — przechwycone payloady siedzą na naszych serwerach przez 24 godziny i w zasadzie mogłyby być przez nas odczytane. Dla produkcyjnych webhooków zawierających sekrety (eventy płatności Stripe, tokeny repo GitHub) użyj narzędzia tunelu-do-localhost (ngrok, cloudflared tunnel), by payload nigdy nie opuszczał Twojego laptopa. To narzędzie jest do dev / staging / jednorazowego debugowania eventów testowych.

Czy mogę dostosować odpowiedź?

Tak — ustaw kod statusu (200, 201, 204, 4xx, 5xx), dodaj nagłówki odpowiedzi (np. Content-Type: application/json) i napisz body odpowiedzi. Przydatne do potwierdzania, że Twój producer obsługuje błędy odpowiedzi poprawnie. Wielu senderów webhooków retry-uje na 5xx; konfigurowanie 500 tu to najprostszy sposób, by zweryfikować zachowanie retry bez dotykania kodu produkcyjnego.