Forem: ShotaTanikawa

Webhook Retry Strategies (2026) — Idempotency, Backoff, Dead Letters

ShotaTanikawa — Wed, 29 Apr 2026 09:31:39 +0000

Stripe will retry your webhook up to 17 times over 3 days. GitHub up to 50 times over 8 hours. Square up to 70 times over 72 hours.

If your code charges a credit card or sends an email when those retries hit, you have a problem.

This is the field guide I wish someone had handed me on day one for building webhook receivers that survive retries. Four pillars: idempotency by event ID, 2xx-fast async processing, understanding each sender's retry policy, and dead-letter handling for the requests that never succeed. Code examples are Node.js + Postgres, but the patterns are language-agnostic.

Quick recipe: dedupe by event ID before doing real work, return 2xx fast, treat duplicates as no-ops, and set up a dead-letter queue for events that fail too many times. The rest is sender-specific tuning.

Why retries are unavoidable

Webhook senders (Stripe, GitHub, Shopify, etc.) decide an event was "delivered" based on whether your endpoint returned a 2xx HTTP status. Anything else — 4xx, 5xx, timeout, TCP reset, your laptop closed mid-deploy — is a "failure" and the sender will try again, often aggressively.

This means your handler is going to see the same event multiple times. Sometimes 2-3 times during a routine outage; up to 17 times for Stripe over 3 days; up to 50 times for GitHub. If your code charges a credit card or sends an email, naïve handling = duplicate charges, duplicate emails, angry customers.

The good news: the fix is mostly mechanical. Once you have idempotency-by-event-ID, retries become benign.

Pillar 1: Idempotency by event ID

Every webhook payload from a serious provider includes a unique event ID:

Provider	Event ID field	Format
Stripe	`id` (top-level)	`evt_1ABC...`
GitHub	`X-GitHub-Delivery` (header)	UUID v4
Shopify	`X-Shopify-Webhook-Id` (header)	UUID v4
Slack	`X-Slack-Request-Timestamp` + body hash	composite
Square	`event_id` (in body)	UUID v4
HubSpot	`eventId` (per event in array)	numeric
SendGrid	`sg_event_id` (per event)	base64

The pattern: persist the event ID before doing real work, in a unique-indexed table. If the insert fails because the ID already exists, you've seen this event before — return 200 OK and do nothing.

CREATE TABLE processed_webhook_events (
  event_id  TEXT PRIMARY KEY,
  source    TEXT NOT NULL,           -- 'stripe', 'github', etc.
  received_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

// Express + node-postgres
import express from "express";
import { Pool } from "pg";

const pool = new Pool();
const app = express();

app.post(
  "/webhooks/stripe",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    // 1. Verify signature first (always — never skip).
    const event = verifyStripeSignature(req); // throws if invalid

    // 2. Try to record the event ID. Unique constraint = dedupe.
    try {
      await pool.query(
        "INSERT INTO processed_webhook_events (event_id, source) VALUES ($1, $2)",
        [event.id, "stripe"],
      );
    } catch (err) {
      if ((err as { code?: string }).code === "23505") {
        // Duplicate — Stripe is retrying. We already handled this event.
        return res.json({ received: true, duplicate: true });
      }
      throw err;
    }

    // 3. Now do real work. If this throws, the row stays in the table
    //    but the event is unprocessed. See "transactional handlers" below.
    await handleStripeEvent(event);

    res.json({ received: true });
  },
);

This is the most important pattern in the entire guide. Get this right and retries become free.

Transactional handlers (the next subtle bug)

The simple version above has a race: if handleStripeEvent throws after we recorded the event ID, retries see "duplicate" and skip the event — but the work never happened. Two fixes:

Option A — Mark events as pending then processed. Use a status column instead of pure existence:

ALTER TABLE processed_webhook_events
  ADD COLUMN status TEXT NOT NULL DEFAULT 'pending',
  ADD COLUMN processed_at TIMESTAMPTZ;

On retry, if a row exists with status='pending', you know the previous attempt died mid-flight. Pick up the work and re-run it. If status='processed', return 200 immediately.

Option B — Wrap the insert + work in a single DB transaction. If the work throws, the insert rolls back, and the next retry sees no row. This is the cleanest pattern when your business logic is also DB-bound:

await pool.query("BEGIN");
try {
  await pool.query(
    "INSERT INTO processed_webhook_events (event_id, source) VALUES ($1, $2)",
    [event.id, "stripe"],
  );
  await handleStripeEvent(event); // does its own DB writes inside the txn
  await pool.query("COMMIT");
} catch (err) {
  await pool.query("ROLLBACK");
  if ((err as { code?: string }).code === "23505") {
    return res.json({ received: true, duplicate: true });
  }
  throw err; // sender will retry; rollback means we're idempotent
}

Option B is the right answer when handlers stay inside one database. Option A is necessary when your handler does external API calls (sending an email, calling Slack, etc.) that can't be rolled back.

Pillar 2: Return 2xx fast — defer work to a queue

Most providers time out at 5-30 seconds. If you do all your processing inline, every slow handler == retry storm. The solution: acknowledge fast, work asynchronously.

app.post("/webhooks/stripe", async (req, res) => {
  const event = verifyStripeSignature(req);

  // Sync: dedupe + enqueue + return.
  await enqueueForProcessing(event); // this is BullMQ / SQS / DB-backed jobs
  res.status(200).json({ received: true });
});

// Worker process — handles the actual logic, retries on its own schedule.
worker.process("stripe-events", async (job) => {
  await handleStripeEvent(job.data);
});

Trade-off: now you have two retry layers (the sender's, and your worker's). Make sure your worker also dedupes by event ID before doing real work — same pattern as Pillar 1.

Pillar 3: Understand each sender's retry policy

You can't tune your dead-letter strategy without knowing the upstream retry budget. The current (2026) policies:

Provider	Retry attempts	Backoff schedule	Total window
Stripe	Up to 17	Exponential, ~immediately → ~3 days	3 days
GitHub	Up to 50	Exponential	~8 hours
Shopify	Up to 19	Exponential, ~hours apart	48 hours
Slack	Up to 3	1 min, 5 min, 30 min	~36 min
Twilio	Configurable (3 default)	Exponential per Webhook config	varies
Square	Up to 70 (!)	Exponential, ~immediately → ~72 hours	72 hours
HubSpot	Up to 10	Exponential	~8 hours
SendGrid	Up to ~24 hours of retries	Exponential	24 hours

Two things this table tells you:

The retry windows are LONG. If Stripe gives you 3 days and Square gives you 72 hours, your handler stability matters over days, not seconds. A "blip" outage that lasts 30 minutes will resolve itself before any of these senders give up.
Slack is the outlier. ~36 minutes of retries means a longer outage drops Slack events on the floor. If Slack signals are critical to your app, you need defensive replay tooling.

Source: each provider's published retry docs as of 2026-04. Re-verify before quoting in production.

Designing for the sender, not against it

A common anti-pattern: returning 4xx for "expected" failures (like a duplicate event you don't care to process). Stripe and most others stop retrying on 4xx; they treat it as "your endpoint rejected the event, that's terminal."

The right responses:

2xx: "I have this. Please don't retry." Use even when you're skipping a duplicate or ignoring an event type.
5xx or timeout: "I'm broken. Please retry." Use for transient infra problems.
4xx: "Don't ever try again." Reserve for malformed requests or signature failures — explicit "stop retrying" intent.

If your endpoint returns 4xx during a partial outage, you'll silently lose events you actually wanted.

Pillar 4: Dead-letter handling

Eventually some events fail every retry. Maybe a customer was deleted between the event firing and your retry, maybe a downstream API changed schemas. You need:

A dead-letter table that captures fully-failed events.
An alert when something lands there.
A manual replay path to reprocess after fixing the bug.

CREATE TABLE webhook_dead_letters (
  id BIGSERIAL PRIMARY KEY,
  source        TEXT NOT NULL,
  event_id      TEXT NOT NULL,
  raw_headers   JSONB NOT NULL,
  raw_body      BYTEA NOT NULL,         -- preserve EXACTLY what arrived
  last_error    TEXT NOT NULL,
  attempts      INT  NOT NULL,
  received_at   TIMESTAMPTZ NOT NULL,
  resolved_at   TIMESTAMPTZ
);

Critical: store the raw bytes of the request, not the parsed JSON. When you fix the handler and want to replay, you need the exact bytes the signature was computed over — otherwise verification fails and you can't retry it cleanly.

Once a row lands here, alert (Slack, PagerDuty, email — whatever you use). Manual replay is then:

async function replayDeadLetter(id: number) {
  const row = await db.oneOrNone(
    "SELECT * FROM webhook_dead_letters WHERE id = $1",
    [id],
  );
  if (!row) throw new Error("not found");

  // Replay through the same handler — your idempotency table
  // ensures we don't double-process if it ALSO hit the live path.
  await processWebhook(row.source, row.raw_headers, row.raw_body);
  await db.none(
    "UPDATE webhook_dead_letters SET resolved_at = now() WHERE id = $1",
    [id],
  );
}

Test your retry handling without waiting for production

The hardest part of this whole architecture is testing. Real Stripe retries happen on Stripe's schedule, days apart. You can't reliably write an integration test against "what happens on the 4th retry."

Two patterns that work:

Use HookRay to capture and replay

I built HookRay specifically because this loop drove me crazy:

Get a free HookRay URL (no signup required for the first 100 captures).
Point Stripe / GitHub / Shopify at the URL in their dashboard.
Trigger a real event (test mode is fine).
From HookRay's UI, click "Replay" — re-send the captured webhook to your local handler (localhost:3000 via tunnel, or HookRay Pro forwards directly).
Click Replay 5 times in a row to verify your idempotency table catches duplicates.

This is the fastest "did my retry handling actually work?" loop I've found.

Provider CLIs

Stripe and GitHub both ship CLI tools that forward real events to localhost:

# Stripe — also supports `--resend-event-id evt_xxx` for replay
stripe listen --forward-to localhost:3000/webhooks/stripe

# GitHub
gh webhook forward --repo owner/repo --url localhost:3000/webhooks/github

These are great for the happy path but they don't simulate the sender's retry storm — for that you need replay (HookRay or roll your own).

Common retry bugs (and how to spot them)

Bug 1: Returning 200 too early. You return 200 then crash before persisting the event. Sender thinks it's done; you lost the data. Fix: persist (or enqueue) before returning 200.

Bug 2: Idempotency on the wrong key. Using a synthetic key (like ${customer_id}_${event_type}) instead of the provider's event ID. Two distinct events with the same composite key collide; legitimate events get dropped as "duplicates." Fix: always dedupe on the provider's event ID.

Bug 3: Returning 4xx for expected duplicates. This stops retries, which sounds good — until you realize that all transient errors during the duplicate path also become 4xx. You silently break legitimate retry. Fix: return 200 OK with {duplicate: true} body for known duplicates; reserve 4xx for truly malformed requests.

Bug 4: Inline external API calls. Your handler calls Stripe's API to fetch related data, the call hangs for 30 seconds, the webhook times out, the sender retries, your handler hangs again, your queue fills up. Fix: enqueue + ack fast (Pillar 2).

Bug 5: Lost events during deploys. Your handler is mid-processing when the container is replaced. The event gets a 5xx (or worse, a half-completed write) and the sender retries. Without graceful shutdown handling, your retry table doesn't capture the in-flight ID. Fix: drain the in-flight queue before deploying, OR use the pending status pattern from Option A above.

Summary checklist

Before declaring your webhook handler "production-ready," verify:

[ ] Every handler dedupes by the provider's event ID
[ ] The dedupe table has a UNIQUE constraint on event_id
[ ] Either Option A (pending → processed) or Option B (transactional) is in use
[ ] Handlers return 2xx on duplicates, NOT 4xx
[ ] Long-running work is enqueued, not done inline
[ ] You have a dead-letter table that stores raw headers + raw body
[ ] You alert on dead-letter inserts (Slack/PagerDuty/email)
[ ] You have a tested manual-replay path
[ ] Your retry handling has been verified with HookRay replay or a similar tool

Pairs naturally with the security half of a robust receiver — see Webhook Signature Verification (HMAC-SHA256) in Node, Python, Ruby — 2026 Guide.

If you want a free webhook URL to capture real Stripe / GitHub / Shopify events and replay them at your local handler, grab one from HookRay — no signup, captures the raw payload + headers exactly as sent.

Drop a 🔖 if this saved you from a duplicate-charge incident, and tell me in the comments which sender's retry behavior has surprised you the most. I'm collecting horror stories for the v2 of this guide.

Webhook Signature Verification (HMAC-SHA256) in Node, Python, Ruby — 2026 Guide

ShotaTanikawa — Wed, 29 Apr 2026 09:25:13 +0000

I review a lot of webhook handlers. Roughly 3 out of 5 either have a subtle signature-verification bug — or someone disabled verification entirely "to make it work." Both leave a public POST endpoint that anyone with the URL can fire fake events at.

If your handler refunds a customer, sends an email, or flips a feature flag, that's a real problem.

This guide is the version I wish someone had handed me on day one: a single HMAC-SHA256 verifier in Node, Python, and Ruby — plus the 6 specific gotchas that break otherwise-correct code on Stripe, GitHub, Shopify, Slack, Twilio, Square, Vercel, HubSpot, Mailgun, SendGrid, Discord, Plaid, and Clerk.

Quick recipe: take the raw request body, compute HMAC-SHA256 with the provider's signing secret, compare against the signature header using a constant-time comparison. That's it. Everything below is just adapting that recipe to specific providers and languages.

Why this matters (and where it goes wrong)

Without signature verification, your webhook handler accepts any POST request that hits your endpoint. An attacker who guesses or scans your URL can fabricate Stripe payment events, GitHub pull request events, etc., and trigger your downstream logic. The damage scales with what your handler does: refunding the wrong customer, creating fake admin accounts, double-firing email campaigns.

The most common mistakes I see in code reviews:

Verifying after the body is parsed. Express's body-parser rebuilds the JSON, then your HMAC computes against the rebuilt string — which differs by even one whitespace character from the original. The signature mismatches, you log a false-positive failure, and you eventually disable verification "to make it work." Don't.
Using === to compare signatures. Allows timing attacks. Use a constant-time compare (crypto.timingSafeEqual in Node, hmac.compare_digest in Python, Rack::Utils.secure_compare in Ruby).
Re-using one secret across endpoints / environments. If your test secret leaks, prod is also at risk. Each endpoint in each environment should have its own secret.
Storing the secret in source code. Use environment variables. If it's already in a commit, rotate it.

The general algorithm

Every HMAC-SHA256 webhook verifier does these four steps:

1. Read the RAW request body (bytes, not parsed JSON).
2. Compute HMAC-SHA256(body, secret) → produces 32 bytes.
3. Hex-encode (or base64-encode) the 32 bytes — match what the provider uses.
4. Compare to the signature header using a constant-time comparison.

Some providers (Stripe) include a timestamp in the signing payload to prevent replay attacks. We'll cover that below.

Node.js (Express): generic HMAC-SHA256 verifier

import crypto from "node:crypto";
import express from "express";

const app = express();

// CRITICAL: capture the raw body so we can verify the signature.
// Do this BEFORE any JSON parser middleware runs.
app.post(
  "/webhook",
  express.raw({ type: "application/json" }),
  (req, res) => {
    const signature = req.header("X-Webhook-Signature");
    if (!signature) return res.status(400).send("Missing signature");

    const expected = crypto
      .createHmac("sha256", process.env.WEBHOOK_SECRET)
      .update(req.body) // req.body is a Buffer here, not a parsed object
      .digest("hex");

    // Constant-time compare to prevent timing attacks
    const sigBuf = Buffer.from(signature, "hex");
    const expBuf = Buffer.from(expected, "hex");
    if (
      sigBuf.length !== expBuf.length ||
      !crypto.timingSafeEqual(sigBuf, expBuf)
    ) {
      return res.status(401).send("Invalid signature");
    }

    // Now safe to parse and process
    const event = JSON.parse(req.body.toString("utf8"));
    handleEvent(event);
    res.status(200).send("OK");
  },
);

function handleEvent(event) {
  // Your business logic
}

The key trick is express.raw({ type: "application/json" }) — this captures the bytes as a Buffer before body-parser would convert them to an object. The signature is computed against the original byte stream, not the rebuilt one.

Stripe-specific: timestamp + signature

Stripe webhooks include a timestamp to prevent replay attacks. The signed string is ${timestamp}.${body}, not just ${body}.

import Stripe from "stripe";
import express from "express";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

app.post(
  "/stripe/webhook",
  express.raw({ type: "application/json" }),
  (req, res) => {
    const signature = req.header("stripe-signature");
    let event;
    try {
      event = stripe.webhooks.constructEvent(
        req.body,
        signature,
        process.env.STRIPE_WEBHOOK_SECRET,
      );
    } catch (err) {
      return res.status(400).send(`Webhook Error: ${err.message}`);
    }

    // event is verified — safe to process
    if (event.type === "checkout.session.completed") {
      // your logic
    }

    res.status(200).send();
  },
);

The Stripe SDK handles all the timestamp + dual-secret + signature parsing for you. Just make sure you pass the raw body.

Python (FastAPI / Flask)

import hmac
import hashlib
import os
from fastapi import FastAPI, Request, HTTPException

app = FastAPI()

@app.post("/webhook")
async def webhook(request: Request):
    signature = request.headers.get("X-Webhook-Signature")
    if not signature:
        raise HTTPException(status_code=400, detail="Missing signature")

    body = await request.body()  # raw bytes
    expected = hmac.new(
        os.environ["WEBHOOK_SECRET"].encode("utf-8"),
        body,
        hashlib.sha256,
    ).hexdigest()

    # Constant-time compare
    if not hmac.compare_digest(signature, expected):
        raise HTTPException(status_code=401, detail="Invalid signature")

    # Now safe to parse
    import json
    event = json.loads(body)
    handle_event(event)
    return {"status": "ok"}


def handle_event(event):
    pass  # your logic

request.body() (FastAPI) and request.get_data() (Flask) both return the raw bytes — exactly what you need for HMAC verification.

For GitHub specifically, the header is X-Hub-Signature-256 and the value is prefixed with sha256=. Strip the prefix:

signature = request.headers.get("X-Hub-Signature-256", "")
if not signature.startswith("sha256="):
    raise HTTPException(status_code=400)
sig_value = signature.removeprefix("sha256=")
# Then compare sig_value to expected as before

Ruby (Rails / Sinatra)

# config/routes.rb (Rails)
post "/webhook", to: "webhooks#receive"

# app/controllers/webhooks_controller.rb
class WebhooksController < ApplicationController
  skip_before_action :verify_authenticity_token

  def receive
    signature = request.headers["X-Webhook-Signature"]
    return head :bad_request unless signature

    body = request.raw_post  # raw bytes, BEFORE Rails JSON parsing
    expected = OpenSSL::HMAC.hexdigest(
      "SHA256",
      ENV.fetch("WEBHOOK_SECRET"),
      body
    )

    # Constant-time compare
    return head :unauthorized unless Rack::Utils.secure_compare(signature, expected)

    event = JSON.parse(body)
    handle_event(event)
    head :ok
  end

  private

  def handle_event(event)
    # your logic
  end
end

request.raw_post (Rails) and request.body.read (Sinatra/Rack) give you the raw bytes. Rack::Utils.secure_compare is constant-time.

Shopify-specific quirk: base64 not hex

Shopify webhooks sign with HMAC-SHA256 but encode in base64, not hex. The verification:

const expected = crypto
  .createHmac("sha256", secret)
  .update(body)
  .digest("base64"); // ← base64, not hex

The header is X-Shopify-Hmac-Sha256.

Per-service signature guides (13 services, 5 algorithm classes)

Different vendors use very different signing models. Most are HMAC-SHA256, but a few break the pattern in ways that catch out copy-pasted verifiers:

Service	Algorithm	Notable quirk
Stripe	HMAC-SHA256 (hex)	`t={ts},v1={sig}` composite header, 5-min replay window
GitHub	HMAC-SHA256 (hex)	`sha256=` prefix; never trust the legacy SHA-1 header
Shopify	HMAC-SHA256 (base64)	Common copy-paste bug: `.digest('hex')` instead of `'base64'`
Slack	HMAC-SHA256 (hex)	Signs `v0:{ts}:{body}` — timestamp window is mandatory
Twilio	HMAC-SHA1 (base64)	URL-based signing; reverse proxies break it
Square	HMAC-SHA256 (base64)	Signs `{notification_url}{body}` — URL is part of message
Vercel	HMAC-SHA1 (hex)	Different secret per source (account / integration / drain)
HubSpot	HMAC-SHA256 (base64)	v3 signs `{method}{URI}{body}{timestamp}`
Mailgun	HMAC-SHA256 (hex)	Signature is in the JSON body, not headers
SendGrid	ECDSA (base64)	Public-key crypto — no shared secret
Discord	Ed25519	Public-key signature on `{ts}{body}`
Plaid	JWT/ES256	Header is a full JWT; fetch public key by `kid`
Clerk	HMAC-SHA256 (Svix)	Three headers: `svix-id`, `svix-timestamp`, `svix-signature`

If your vendor isn't here, the generic HMAC verifier above covers ~70% of cases. The exceptions to watch for: base64-vs-hex (Shopify, Square), composite signed strings (Stripe, Slack, Square, HubSpot), public-key (Discord, SendGrid, Plaid), or the signature living in the body instead of the headers (Mailgun).

How to test signature verification without deploying

Verifying signatures locally is the part most engineers get wrong because the secret + raw-body combination is finicky. Two recommended workflows:

Option A: capture real webhooks with HookRay, replay locally

I built this workflow because the alternatives drove me nuts:

Get a free HookRay URL (no signup).
Paste it into Stripe / GitHub / Shopify dashboard webhook settings.
Trigger a test event. HookRay captures the raw body + headers exactly as sent (including X-Hub-Signature-256, stripe-signature, etc.).
Use HookRay's Replay feature to re-send the captured webhook to http://localhost:3000/webhook (with a tunnel like ngrok if needed, or use HookRay Pro to forward directly).
Your local code receives the EXACT same bytes Stripe/GitHub sent. If verification fails, the bug is in your code, not in transmission.

This isolates "is my code right?" from "is the network mangling the body?" — by far the most common source of false-negative failures.

Option B: use the provider's CLI (Stripe / GitHub specific)

Stripe: stripe listen --forward-to localhost:3000/webhook lets the Stripe CLI forward real test events directly to your local server.

GitHub: install smee.io or use the official GitHub CLI gh webhook forward.

These work but lock you to one provider's tooling.

Common verification failures (with fixes)

Symptom	Cause	Fix
"signature mismatch" but you copy-pasted the secret	Body was JSON-parsed before HMAC	Use raw body / Buffer / bytes
Stripe SDK throws "No signatures found matching..."	Wrong secret (test vs. live, or wrong endpoint)	Each Stripe endpoint has its own secret — copy from the correct one
GitHub `X-Hub-Signature-256` doesn't match	Forgot `sha256=` prefix in header value	Strip the prefix before comparison
Shopify mismatch despite correct secret	Hex vs. base64 encoding	Use `digest("base64")` for Shopify
Works locally, fails in production	Different secret in env vars	Sync env vars; rotate secret if leaked
Intermittent failures (some events pass, some fail)	Body parser middleware running before raw capture in some routes	Add raw-body middleware ONLY to webhook routes

Summary

Raw body always. Never compute HMAC against re-parsed JSON.
Constant-time compare always. ===, ==, or string equality leak timing information.
One secret per environment per endpoint. Rotate on leak.
Test with real captured payloads. HookRay or the provider's CLI both work.

Signature verification is the security half of a robust receiver. The reliability half — idempotency, retries, dead-letter handling — is a whole separate beast that I covered in Webhook Retry Strategies (2026): Idempotency, Backoff, Dead Letters.

If you want a free webhook URL to test signature verification with, HookRay gives you one in 5 seconds — no signup, captures raw payload + signature headers exactly as sent.

If you found this useful, drop a 🔖 — and tell me in the comments which provider's signing scheme has hurt you the most. I'm building a service-by-service guide and the wildest stories tend to point at the worst documentation.

I shipped a dev tool 30 days ago. 881 impressions, 8 clicks, $0 MRR. Here's the data.

ShotaTanikawa — Tue, 21 Apr 2026 23:55:53 +0000

30 days ago I shipped HookRay — a webhook testing tool meant to compete with webhook.site — and committed to publishing real numbers at the 30-day mark.

Here are the numbers. They're humbling, but I think other indie hackers will get more from honest data than from another "I hit $10K MRR" post.

The product

HookRay (hookray.com) — webhook testing tool with real-time updates, search, replay, and smart payload parsing for Stripe, GitHub, Shopify, etc. Built because webhook.site's 50-request URL expiration was driving me crazy.

Stack: Next.js 16, Supabase, Stripe, Vercel. Solo, ~3 weeks build time.

The 28-day Search Console data

Metric	Value
Impressions	881
Clicks	8
CTR	0.9%
Avg position	12.1
Indexed pages	22 / 126 (17%)
Signups	2
Paying customers	0
MRR	$0

That's ~31 impressions/day, 0.3 clicks/day. A big fat nothing.

Three things the data told me I didn't expect

1. The article I thought would win didn't

I assumed webhook.site alternative keywords would drive traffic. My comparison article ranks position 10 — top of page 2, basically invisible. People searching this are probably seeing webhook.site, a few others, then giving up before clicking page 2.

2. The SEO is winning on the wrong product

My accidental top performer is the QR code API comparison article. It's ranking:

Position 2.7 for best javascript qr code library 2026 (6 impressions, 0 clicks)
Position 4.5 for qrserver api status 2026 (6 imp, 0 clicks)
Position 5.6 for qrserver api still working 2026 (7 imp, 0 clicks)

Those queries are all people worried api.qrserver.com is dying. None of them came to read a comparison — they came for a status check. I was serving the wrong intent at the right position.

3. Position 2-3 with 0% CTR means meta is broken, not content

Getting to position 2-3 organically is hard. Getting 0 clicks from that is a title/meta problem, not a ranking problem. For "qrserver api still working 2026", my article title was "Best QR Code API for Developers in 2026" — which doesn't answer the worry the user is bringing.

What I actually did about it

This week I rewrote the QR article based on what the data was telling me:

New title: Best QR Code API 2026: QRServer Alternatives + HookRay Compared
Added a dedicated top-of-article section: "Is api.qrserver.com Still Working in 2026?" answering the search intent honestly
Added a migration snippet showing how to swap api.qrserver.com URLs for the HookRay QR API

I'll know in 7-14 days whether CTR moves. If it goes from 0% to even 3%, I've tripled my total site traffic without writing a new article.

What I'm NOT doing

I resisted every indie-hacker instinct to "build more features" this week:

Not adding custom response codes to HookRay (the #1 webhook.site feature I'm missing). Features don't fix distribution.
Not spinning out QR into its own domain (my gut said yes, the data says wait — still too early).
Not pivoting the whole product. 881 impressions is not enough signal to pivot on.

The uncomfortable truth about SEO + indie products

60-70% of indie hackers never reach $1 MRR. Most fail at distribution, not product. I'm in that valley right now, and SEO alone is a 6-12 month play.

So I'm pairing SEO with faster-burn distribution — Dev.to posts like this one, Reddit, a Product Hunt launch in a few weeks. Transparency + data does well here, and the SEO compounds in the background.

Questions for this community

Anyone else had SEO surface a niche you didn't plan for? Did you lean in or stay on original course?
For those who hit $1-100 MRR: what was the distribution channel that actually worked, vs what you thought would work?
Is there a single worst-ROI activity you wish you'd skipped in your first 3 months?

I'll update this post with numbers at day 60. Drop your email in the comments or follow for the update if you want the receipts.

— Shota

HookRay is live at hookray.com. If you're testing webhooks and want a free alternative to webhook.site, that's where it lives.

5 Free Developer Tools You Can Use Without Signing Up

ShotaTanikawa — Thu, 02 Apr 2026 00:26:39 +0000

There's a special kind of friction that kills productivity: the signup wall. You need to generate a QR code for a demo, grab a screenshot of a client's site, or validate a list of emails — and every tool wants your email address first.

I built a set of browser-based tools that skip all of that. No accounts, no API keys, no "verify your email" loops. Open the page, use the tool, get your result.

Here are 5 that I use regularly in my own workflow.

1. QR Code Generator

What it does: Generates QR codes from any text or URL with customizable foreground/background colors. Export as PNG or SVG.

When you'd use it: You're building a mobile app and need a QR code pointing to your staging URL for device testing. Or you're preparing slides for a talk and want attendees to scan a link to your repo. Either way, you need it in 10 seconds, not after creating an account on some QR platform.

What it looks like: A clean single-page form with a text input at the top, color pickers for foreground and background, a format toggle (PNG/SVG), and a live preview of the generated QR code on the right. Hit "Generate" and download directly.

Try it -> hookray.com/tools/qrcode

2. Website Screenshot Tool

What it does: Takes full-page screenshots of any URL. Supports PNG, JPEG, and WebP output formats.

When you'd use it: You're writing documentation and need a screenshot of a third-party API's dashboard. Or you're doing a competitor analysis and want to archive how their landing page looks today. Or you just need a quick visual for a PR description. Point it at a URL, pick a format, download the image.

What it looks like: A URL input field with format and viewport options below it. After capturing, it shows the full rendered screenshot with a download button. No watermarks, no "upgrade for full resolution" tricks.

Try it -> hookray.com/tools/screenshot

3. HTML to PDF Converter

What it does: Converts any URL or raw HTML into a PDF with configurable paper size (A4, Letter, etc.) and orientation options.

When you'd use it: You need to turn a styled HTML invoice into a downloadable PDF. Or you're archiving a web page that might change. Or your client asks "can you send this as a PDF?" and you don't want to fight with print stylesheets. Paste the URL or HTML, pick your paper size, get a PDF.

What it looks like: Two input modes — a URL field or an HTML code editor. Below that, paper size and orientation dropdowns. Click convert, preview the PDF inline, and download it. Straightforward, no steps wasted.

Try it -> hookray.com/tools/pdf

4. AI Text Summarizer

What it does: Summarizes long text into a paragraph, bullet points, or a one-line TL;DR. Useful for digesting documentation, articles, or meeting notes quickly.

When you'd use it: You're reviewing a 3,000-word RFC from another team and need to get the gist before a meeting in 5 minutes. Or you're writing release notes and want to condense a long changelog into bullet points. Paste the text, pick a format, get the summary.

What it looks like: A large text area for pasting content, a format selector (paragraph / bullet points / TL;DR), and a "Summarize" button. The output appears below with a copy button. Clean and minimal — no distracting options.

Try it -> hookray.com/tools/summarizer

5. Email Validator

What it does: Validates email addresses by checking format, DNS records, MX records, disposable email detection, and common typo suggestions (e.g., "gmial.com" -> "gmail.com").

When you'd use it: You're building a signup form and want to catch bad emails before they hit your database. Or you're cleaning a CSV of leads and need to know which ones will bounce. Or you just want to check if a domain even has mail servers configured. Paste an email, get a full breakdown.

What it looks like: A single email input at the top with a "Validate" button. Results appear as a checklist: format valid, DNS exists, MX records found, not disposable, no typos detected. Each check shows a green pass or red fail with details. If a typo is detected, it suggests the correction.

Try it -> hookray.com/tools/email-validator

Why No Signup?

I've been on the other side of these tools too many times. You Google "free QR code generator," click the first result, and immediately get hit with a registration form. For a QR code.

These tools are part of HookRay — a developer toolkit I'm building. The philosophy is simple: if a tool takes 10 seconds to use, it shouldn't take 60 seconds to access.

If any of these saved you a few minutes, I'd appreciate a bookmark or a share. And if you have ideas for other tools that should exist without a signup wall, I'd genuinely like to hear them in the comments.

I built a webhook testing tool with 80+ testing guides — here's how

ShotaTanikawa — Mon, 30 Mar 2026 00:03:12 +0000

Building webhook integrations is painful. You set up a test URL, it expires, payloads disappear, and you're left guessing what went wrong.

So I built HookRay — a webhook testing and debugging tool.

What it does

Instant webhook URLs — create a test endpoint in one click, no signup required
Real-time inspection — see every incoming request with parsed JSON payloads
Search & filter — find requests by HTTP method, time range, or body content
Replay — re-send any captured webhook to a target URL for debugging
Team sharing — collaborate with your team on shared endpoints

The tech stack

Next.js 16 (App Router) + React 19
Supabase for auth and PostgreSQL
Stripe for subscription billing
Vercel for deployment
Claude API for AI-powered features

80+ webhook testing guides

I created step-by-step guides for testing webhooks from popular services:

Each guide covers event types, sample payloads, and common debugging tips.

9 APIs on RapidAPI

Beyond the webhook tool, I built a portfolio of developer APIs:

AI SEO Meta Tag Generator — generate optimized meta tags from any URL (try it)
Web Page Summarizer — summarize any page in up to 5 languages simultaneously (try it)
QR Code Generator, Screenshot API, HTML to PDF, Email Validation, and more

Lessons learned

Building is the easy part. I shipped everything in ~2 weeks using AI coding tools. Getting users is 10x harder.
SEO takes patience. 116 pages, proper sitemaps, JSON-LD — and Google has indexed only a handful so far.
Distribution > Product. No one will use your tool if they can't find it.

I'm a solo developer from Japan, trying to build side income from developer tools. Would love feedback or advice from anyone who's done this successfully.

👉 hookray.com

Summarize Any Text with AI - Paragraph Bullets or TLDR

ShotaTanikawa — Fri, 20 Mar 2026 17:39:26 +0000

Summarize Any Text with AI — Paragraph, Bullets, or TL;DR

The AI Text Summarizer API condenses long text into concise summaries using Claude AI. Choose your format: flowing paragraph, bullet points, or a single TL;DR sentence. Supports 5 languages.

Quick Start

curl -X POST https://summarizer-api-zeta.vercel.app/api/summarize \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Your long article text here...",
    "format": "tldr",
    "language": "en"
  }'

Response:

{
  "summary": "The article discusses the key impacts of AI on modern software development.",
  "word_count": 12,
  "original_word_count": 850,
  "compression_ratio": 0.0141,
  "language": "en",
  "format": "tldr"
}

Three Formats

Paragraph (default)

{"format": "paragraph", "max_length": 100}

Returns a flowing prose summary in 1-2 paragraphs.

Bullet Points

{"format": "bullets", "max_length": 100}

Returns key points as a bullet list:

• First key point
• Second key point
• Third key point

TL;DR

{"format": "tldr"}

Returns a single sentence capturing the essence.

Supported Languages

en (English), ja (Japanese), es (Spanish), fr (French), de (German)

Python Example

import requests

article = open("long_article.txt").read()

result = requests.post(
    "https://summarizer-api-zeta.vercel.app/api/summarize",
    json={
        "text": article,
        "format": "bullets",
        "max_length": 50,
        "language": "en",
    },
).json()

print(f"Compressed {result['original_word_count']} words to {result['word_count']} words")
print(f"Compression: {(1 - result['compression_ratio']) * 100:.0f}%")
print(result["summary"])

Use Cases

News aggregation: Summarize articles for digest emails
Content curation: Create previews for link roundups
Document processing: Extract key points from reports
Accessibility: Provide quick summaries for long-form content
Slack/Discord bots: Auto-summarize shared links

Try It

Available on RapidAPI with a free tier.

Built by @ShotaTanikawa

Generate QR Codes with a Free API (PNG & SVG)

ShotaTanikawa — Fri, 20 Mar 2026 16:54:43 +0000

Generate QR Codes with a Free API (PNG & SVG)

Need QR codes in your app? The QR Code Generator API creates customizable QR codes from any text or URL. Supports PNG and SVG, custom colors, and sizes up to 2000px.

Quick Start

POST (JSON body)

curl -X POST https://qrcode-api-eight.vercel.app/api/generate \
  -H "Content-Type: application/json" \
  -d '{"data": "https://example.com", "size": 400}' \
  --output qrcode.png

GET (query params — perfect for img tags!)

<img src="https://qrcode-api-eight.vercel.app/api/generate?data=https://example.com&size=200" />

Yes, you can use it directly in <img> tags. No JavaScript needed.

Options

Parameter	Type	Default	Description
`data`	string	required	Text or URL to encode
`size`	number	300	Image size in pixels (100-2000)
`format`	string	"png"	png or svg
`errorCorrectionLevel`	string	"M"	L, M, Q, or H
`margin`	number	4	Quiet zone (0-10)
`darkColor`	string	"#000000"	Hex color for dark modules
`lightColor`	string	"#ffffff"	Hex color for light modules

Custom Colors Example

curl -X POST https://qrcode-api-eight.vercel.app/api/generate \
  -H "Content-Type: application/json" \
  -d '{"data": "Hello!", "darkColor": "#1a56db", "lightColor": "#f0f4ff", "size": 500}' \
  --output blue-qr.png

Python Example

import requests

response = requests.post(
    "https://qrcode-api-eight.vercel.app/api/generate",
    json={"data": "https://mysite.com", "format": "svg"},
)

with open("qrcode.svg", "w") as f:
    f.write(response.text)

Use Cases

Product packaging: Generate QR codes for product URLs
Event tickets: Encode ticket IDs in scannable QR codes
Business cards: Link to your portfolio or LinkedIn
Restaurant menus: Link to digital menus
Marketing: Track campaign URLs with QR codes

Try It

Available on RapidAPI with a generous free tier (200 requests/month).

Built by @ShotaTanikawa

Capture Website Screenshots with a Simple API Call

ShotaTanikawa — Fri, 20 Mar 2026 16:54:42 +0000

Capture Website Screenshots with a Simple API Call

Need to generate thumbnails, create visual previews, or capture website screenshots programmatically? The Website Screenshot API lets you do it in one HTTP request.

Quick Start

curl -X POST https://screenshot-api-rouge-zeta.vercel.app/api/screenshot \
  -H "Content-Type: application/json" \
  -d '{"url": "https://github.com", "width": 1280, "height": 720}' \
  --output screenshot.png

That's it. You get a pixel-perfect PNG screenshot back.

Options

Parameter	Type	Default	Description
`url`	string	—	URL to capture
`html`	string	—	Raw HTML to render
`format`	string	"png"	png, jpeg, or webp
`width`	number	1280	Viewport width (max 3840)
`height`	number	720	Viewport height (max 2160)
`fullPage`	boolean	false	Capture full scrollable page
`deviceScaleFactor`	number	1	Retina scaling (1-3)
`delay`	number	0	Wait ms after page load

Python Example

import requests

response = requests.post(
    "https://screenshot-api-rouge-zeta.vercel.app/api/screenshot",
    json={"url": "https://example.com", "format": "jpeg", "width": 1920, "height": 1080},
)

with open("screenshot.jpg", "wb") as f:
    f.write(response.content)

Node.js Example

const response = await fetch("https://screenshot-api-rouge-zeta.vercel.app/api/screenshot", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ url: "https://example.com", fullPage: true }),
});

const buffer = await response.arrayBuffer();
require("fs").writeFileSync("screenshot.png", Buffer.from(buffer));

Use Cases

Social media previews: Generate OG images from URLs
Visual regression testing: Compare screenshots across deployments
Thumbnail generation: Create previews for link directories
Archiving: Save webpages as images
Monitoring: Capture visual state of websites periodically

Try It

Available on RapidAPI with a free tier.

Built by @ShotaTanikawa. Feedback welcome!

Convert Any HTML or URL to PDF with a Simple API Call

ShotaTanikawa — Fri, 20 Mar 2026 05:15:08 +0000

Convert Any HTML or URL to PDF with a Simple API Call

Need to generate PDFs from your web app? Invoices, reports, receipts, or just saving a webpage as PDF? The HTML to PDF Converter API does it in one API call — no Puppeteer setup, no server management, no headless browser configuration.

Quick Start

Convert HTML to PDF

curl -X POST https://pdf-api-mu.vercel.app/api/convert \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<h1>Invoice #1234</h1><p>Amount: $49.99</p><p>Date: 2026-03-20</p>",
    "format": "A4",
    "margin": {"top": "25mm", "right": "20mm", "bottom": "25mm", "left": "20mm"}
  }' \
  --output invoice.pdf

Convert a URL to PDF

curl -X POST https://pdf-api-mu.vercel.app/api/convert \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}' \
  --output page.pdf

That's it. You get a production-quality PDF back.

Options

Parameter	Type	Default	Description
`html`	string	—	Raw HTML to convert
`url`	string	—	URL to convert
`format`	string	"A4"	A0-A6, Letter, Legal, Tabloid, Ledger
`landscape`	boolean	false	Landscape orientation
`margin`	object	20mm all	Top, right, bottom, left margins
`printBackground`	boolean	true	Include background colors/images

Provide either html or url, not both.

Python Example

import requests

# Generate an invoice PDF
response = requests.post(
    "https://pdf-api-mu.vercel.app/api/convert",
    json={
        "html": """
        <style>
            body { font-family: Arial, sans-serif; }
            .header { border-bottom: 2px solid #333; padding-bottom: 10px; }
            .total { font-size: 24px; font-weight: bold; margin-top: 20px; }
        </style>
        <div class="header">
            <h1>Invoice #2024-001</h1>
            <p>Date: March 20, 2026</p>
        </div>
        <table>
            <tr><td>Web Development</td><td>$2,000</td></tr>
            <tr><td>API Integration</td><td>$500</td></tr>
        </table>
        <div class="total">Total: $2,500</div>
        """,
        "format": "A4",
    },
)

with open("invoice.pdf", "wb") as f:
    f.write(response.content)

print("Invoice saved!")

Node.js Example

const response = await fetch("https://pdf-api-mu.vercel.app/api/convert", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    url: "https://github.com/ShotaTanikawa",
    format: "A4",
    printBackground: true,
  }),
});

const buffer = await response.arrayBuffer();
const fs = await import("fs");
fs.writeFileSync("github-profile.pdf", Buffer.from(buffer));
console.log("PDF saved!");

Use Cases

Invoice generation: HTML template → professional PDF invoice
Report exports: Dashboard data → downloadable PDF report
Receipt generation: Order confirmation → PDF receipt for email
Web archiving: Save any webpage as a PDF document
Resume/CV: HTML resume → PDF for job applications
Legal documents: Terms of service → formatted PDF

Why Not Just Use Puppeteer Directly?

You could. But then you need:

A server to run headless Chromium (1GB+ RAM)
Chromium binary management and updates
Timeout handling, memory leak prevention
Scaling for concurrent requests

Or you can make one API call and get a PDF back. Your choice.

Try It

Available on RapidAPI with a free tier (100 PDFs/month).

Built by @ShotaTanikawa. Feedback welcome!

Generate E-Commerce Product Descriptions with AI (API Tutorial)

ShotaTanikawa — Fri, 20 Mar 2026 04:58:23 +0000

Generate E-Commerce Product Descriptions with AI (API Tutorial)

Writing product descriptions is one of the most tedious parts of running an online store. You need SEO-friendly titles, compelling descriptions, and relevant hashtags — for every single product.

In this tutorial, I'll show you how to automate this with the Product Description Generator API, which uses Claude AI to generate professional product copy in seconds.

What You Get

For each product, the API generates:

3 title options (SEO-optimized, under 60 characters)
3 description options (100-200 words, ready for Shopify/Etsy/Amazon)
15 hashtags (for Instagram/TikTok social selling)

Quick Start

cURL

curl -X POST https://description-api-omega.vercel.app/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "product_name": "Handmade Ceramic Coffee Mug",
    "category": "Kitchen",
    "features": "Hand-thrown stoneware, 12oz capacity, microwave safe, unique glaze",
    "appeal": "Perfect morning coffee ritual, each piece is one-of-a-kind",
    "tone": "handmade",
    "language": "en"
  }'

Response

{
  "titles": [
    "Hand-Thrown Stoneware Coffee Mug – One of a Kind",
    "Artisan Ceramic Mug – Unique Glaze, 12oz",
    "Handcrafted Coffee Mug – Microwave Safe Stoneware"
  ],
  "descriptions": [
    "Start your morning ritual with a mug that tells a story. Each hand-thrown stoneware coffee mug is crafted with care, featuring a unique glaze pattern that ensures no two pieces are exactly alike...",
    "There's something special about wrapping your hands around a mug that was shaped by human hands...",
    "Elevate your daily coffee experience with this beautifully crafted 12oz stoneware mug..."
  ],
  "hashtags": "#HandmadeCeramics #CoffeeMug #Stoneware #PotteryLove #ArtisanMade #UniqueGlaze #MorningCoffee #HandThrown #CeramicArt #KitchenDecor #CoffeeLover #OneOfAKind #ShopHandmade #PotteryMug #CraftedWithLove"
}

Supported Tones

Tone	Style	Best For
`professional`	Polished, trustworthy	B2B, electronics, professional gear
`casual`	Friendly, approachable	Everyday items, food, casual wear
`luxury`	Elegant, sophisticated	Jewelry, fashion, premium goods
`playful`	Fun, energetic	Kids products, novelty items, games
`handmade`	Warm, artisanal	Crafts, handmade goods, Etsy shops

Supported Languages

en (English), ja (Japanese), es (Spanish), fr (French), de (German)

Japanese Example

curl -X POST https://description-api-omega.vercel.app/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "product_name": "手編みウールマフラー",
    "category": "ファッション",
    "features": "メリノウール100%, 手編み, 180cm",
    "tone": "handmade",
    "language": "ja"
  }'

Python Example

import requests

response = requests.post(
    "https://description-api-omega.vercel.app/api/generate",
    json={
        "product_name": "Leather Laptop Sleeve",
        "category": "Accessories",
        "features": "Full grain leather, fits 13-14 inch laptops, felt lining",
        "appeal": "Professional look for remote workers and digital nomads",
        "tone": "professional",
        "language": "en",
    },
)

data = response.json()

print("=== Titles ===")
for title in data["titles"]:
    print(f"  {title}")

print("\n=== Best Description ===")
print(data["descriptions"][0])

print(f"\n=== Hashtags ===")
print(data["hashtags"])

Node.js Example

const response = await fetch(
  "https://description-api-omega.vercel.app/api/generate",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      product_name: "Wireless Bluetooth Speaker",
      category: "Electronics",
      features: "IPX7 waterproof, 24hr battery, 360 sound",
      appeal: "Take your music anywhere",
      tone: "casual",
      language: "en",
    }),
  }
);

const { titles, descriptions, hashtags } = await response.json();
console.log(titles[0]); // Best title
console.log(descriptions[0]); // Best description

Batch Processing (Multiple Products)

import requests

products = [
    {"product_name": "Silver Earrings", "category": "Jewelry", "tone": "luxury"},
    {"product_name": "Organic Soap", "category": "Beauty", "tone": "natural"},
    {"product_name": "Kids T-Shirt", "category": "Clothing", "tone": "playful"},
]

for product in products:
    product["language"] = "en"
    resp = requests.post(
        "https://description-api-omega.vercel.app/api/generate",
        json=product,
    )
    data = resp.json()
    print(f"\n--- {product['product_name']} ---")
    print(f"Title: {data['titles'][0]}")
    print(f"Description: {data['descriptions'][0][:100]}...")

Use Cases

Shopify/Etsy sellers: Generate descriptions for new listings in seconds
Dropshipping: Create unique descriptions instead of copying supplier text
Social media: Get ready-made hashtags for Instagram/TikTok product posts
Multilingual stores: Generate descriptions in 5 languages from one input
A/B testing: Get 3 variations to test which converts best

Try It

Available on RapidAPI with a free tier (50 requests/month).

Built by @ShotaTanikawa. Feedback and feature requests welcome!

How to Capture and Inspect Webhooks with a Free API

ShotaTanikawa — Fri, 20 Mar 2026 04:58:07 +0000

How to Capture and Inspect Webhooks with a Free API

If you've ever built a Stripe integration, a GitHub Action, or a Shopify app, you know the pain of testing webhooks during development. You set up an endpoint, trigger an event, and then... where did the data go?

In this tutorial, I'll show you how to use the Webhook Receiver API to capture, inspect, and retrieve webhook payloads — all without setting up any infrastructure.

The Problem

During development, you need to:

Receive webhooks from external services (Stripe, GitHub, etc.)
See what data they're sending
Verify headers, signatures, and payload structure

Most developers use console.log and pray. There's a better way.

Quick Start (2 minutes)

Step 1: Create an Endpoint

curl -X POST https://hookray.com/api/endpoints

Response:

{
  "endpoint": {
    "slug": "a1b2c3d4",
    "expires_at": "2026-03-21T00:00:00Z",
    "request_count": 0,
    "max_requests": 100
  }
}

Your webhook URL is now: https://hookray.com/api/hook/a1b2c3d4

Step 2: Send a Webhook

Point any service to your URL, or test manually:

curl -X POST https://hookray.com/api/hook/a1b2c3d4 \
  -H "Content-Type: application/json" \
  -H "X-Custom-Header: my-value" \
  -d '{"event": "order.completed", "amount": 49.99}'

Response: {"ok": true}

Step 3: Retrieve Captured Data

curl https://hookray.com/api/hook/a1b2c3d4/requests

Response:

{
  "endpoint": {
    "slug": "a1b2c3d4",
    "request_count": 1,
    "max_requests": 100
  },
  "requests": [
    {
      "method": "POST",
      "headers": {
        "content-type": "application/json",
        "x-custom-header": "my-value"
      },
      "body": "{\"event\": \"order.completed\", \"amount\": 49.99}",
      "query_params": {},
      "source_ip": "203.0.113.1",
      "created_at": "2026-03-20T12:00:00Z"
    }
  ]
}

Every header, every byte of the body, every query parameter — captured and stored.

Real-World Example: Testing Stripe Webhooks

# 1. Create endpoint
SLUG=$(curl -s -X POST https://hookray.com/api/endpoints | jq -r '.endpoint.slug')
echo "Webhook URL: https://hookray.com/api/hook/$SLUG"

# 2. Set this URL in Stripe Dashboard → Developers → Webhooks

# 3. Trigger a test event in Stripe

# 4. Retrieve the webhook data
curl -s "https://hookray.com/api/hook/$SLUG/requests" | jq '.requests[0].body' -r | jq .

Python Example

import requests

# Create endpoint
resp = requests.post("https://hookray.com/api/endpoints")
slug = resp.json()["endpoint"]["slug"]
print(f"Webhook URL: https://hookray.com/api/hook/{slug}")

# ... configure your service to send webhooks to the URL ...

# Retrieve captured webhooks
resp = requests.get(f"https://hookray.com/api/hook/{slug}/requests")
for req in resp.json()["requests"]:
    print(f"{req['method']} - {req['content_type']} - {req['created_at']}")
    print(req["body"])

Node.js Example

const BASE = "https://hookray.com";

// Create endpoint
const { endpoint } = await fetch(`${BASE}/api/endpoints`, {
  method: "POST",
}).then((r) => r.json());

console.log(`Webhook URL: ${BASE}/api/hook/${endpoint.slug}`);

// Retrieve captured webhooks
const { requests } = await fetch(
  `${BASE}/api/hook/${endpoint.slug}/requests`
).then((r) => r.json());

requests.forEach((req) => {
  console.log(`${req.method} ${req.content_type} ${req.created_at}`);
  console.log(JSON.parse(req.body));
});

Features

Any HTTP method: GET, POST, PUT, PATCH, DELETE — all captured
Full headers: Every request header is stored
Query parameters: ?key=value pairs are parsed and stored
Source IP: Know where the request came from
Free tier: 100 requests per endpoint, expires in 24 hours
No signup required: Create an endpoint and start capturing immediately

Try It Now

The API is available on RapidAPI with a free tier, or use it directly at hookray.com.

You can also use the web dashboard at hookray.com/app for a visual, real-time view of incoming webhooks.

Built by @ShotaTanikawa. If this helped you, a ⭐ on the API listing would be appreciated!