Forem: Peakline Studio

webhook.site Alternatives in 2026: Free Tools for Testing and Inspecting Webhooks

Peakline Studio — Mon, 30 Mar 2026 17:18:03 +0000

Webhooks are everywhere in 2026 — Stripe, GitHub, Slack, Shopify, Twilio, and hundreds of other services push events to your endpoints. But testing them without a running server is annoying. That's where hosted webhook inspection tools come in.

This post compares the main options in 2026, so you can pick the right tool for your workflow.

What you actually need from a webhook testing tool

Before comparing, let's nail down the requirements:

Unique inspection URL — a real HTTPS endpoint that accepts any HTTP method
Real-time request viewing — see headers, body, query params instantly
Payload replay — resend captured payloads to your local server without re-triggering the original event
Persistence — saved history for debugging after the fact
Transform rules — filter or mask sensitive data before storing (useful for Stripe payloads with card data)

The main free options

webhook.site

The OG. Generates a unique URL instantly, no account needed. Clean UI, shows headers, body, and query params in real-time.

Free plan limits: 50 requests per URL, URLs expire. Paid plans start at $7.50/month for unlimited requests and workflows.

Best for: quick one-off tests where you just need to confirm a webhook fired.

Not great for: long-running debug sessions, replaying payloads, or teams sharing endpoints.

RequestBin (via Pipedream)

RequestBin was acquired by Pipedream and relaunched as part of their platform. It still gives you a free inspection URL, but it's now deeply integrated with Pipedream's workflow automation.

Free plan limits: limited event history, account required.

Best for: developers already using Pipedream who want to chain webhooks into automations.

Not great for: pure webhook inspection — the UI has become automation-first.

ngrok (inspect mode)

ngrok is primarily a tunnel to localhost, but its web inspector at localhost:4040 is excellent for debugging webhooks hitting your local dev environment.

Free plan limits: ngrok URLs change on restart (unless paid), connection limits apply.

Best for: developers who need to test against a locally running service.

Not great for: sharing URLs with external services or when you don't want to keep a local process running.

HookTest

HookTest is a newer option that addresses some of the gaps in the tools above.

Free plan: 3 endpoints, 24-hour TTL, real-time inspection — no account needed.

What's different:

Payload replay — resend any captured webhook to a different target URL. Useful when you want to replay a Stripe event to your local ngrok endpoint without re-triggering the actual Stripe flow.
Transform rules — mask, rename, or filter fields in payloads before they're stored. Handy when Stripe payloads include partial card data and you want to avoid logging it.
Works without ngrok — endpoints are real HTTPS URLs with no local process required.

Pro plan ($9/month): 10 persistent endpoints, transform rules, extended history.

Quick comparison table

Feature	webhook.site	RequestBin	ngrok inspect	HookTest
No account needed	✓	✗	✗	✓
Real-time inspect	✓	✓	✓	✓
Payload replay	✗	✗	✓ (local only)	✓
Transform/mask fields	✗ (paid)	✗	✗	✓
Persistent history	✗ (free)	limited	✗	✗ (free) / ✓ (pro)
Custom domain	✗ (free)	✗	✓ (paid)	upcoming
Free request limit	50/URL	limited	unlimited (local)	100/endpoint

Choosing the right tool

Quick one-time test → webhook.site (fastest, no friction)
Local development + debugging → ngrok
Workflow automation → RequestBin via Pipedream
Replay, masking, team use → HookTest

The real workflow killer is having to re-trigger events from the source to debug a payload parsing issue. With replay, you capture the event once and resend it as many times as you need — even to a different URL (like your localhost).

Have a different webhook testing tool you swear by? Drop it in the comments.

How to Auto-Generate API Documentation from Any GitHub Repo (Without Writing a Word)

Peakline Studio — Mon, 30 Mar 2026 17:17:55 +0000

Good API documentation is one of those things everyone agrees matters and almost nobody keeps up to date.

The README gets written during the launch sprint, then drifts from reality as endpoints change, parameters shift, and the intern who wrote the original docs has moved on.

Here's a way to fix that without writing anything by hand.

The problem with manual docs

The standard approach to API documentation looks like this:

Write docs by hand during initial development
Forget to update them when the API changes
Get bug reports from users who followed the now-wrong docs
Repeat

The alternative — auto-generating docs from code — has existed for years (Swagger/OpenAPI, JSDoc, etc.), but it requires you to annotate your code first. Which is also a thing nobody keeps up to date.

A different approach: generate from the code itself

What if you could point a tool at any GitHub repo and get back a full README, API reference, and usage examples — with no annotations required?

That's what the Code Documentation Generator API does. It fetches your repository, analyzes the actual code structure, and generates contextual documentation.

How it works

The API has three endpoints:

/generate/full — generates a complete README + API reference in one shot
/generate/readme — README only (project overview, installation, usage, examples)
/generate/api-reference — API reference only (endpoints, parameters, return types, error codes)

Basic usage

curl -X POST "https://code-docs-api.peakline-ops.workers.dev/generate/readme" \
  -H "Content-Type: application/json" \
  -d '{
    "repo_url": "https://github.com/your-org/your-repo",
    "doc_type": "readme"
  }'

Response:

{
  "success": true,
  "documentation": "# Your Project

A REST API for...",
  "repo": "your-org/your-repo",
  "type": "readme",
  "cached": false
}

Results are cached for 24 hours, so regenerating docs on a CI run is fast after the first call.

Automate it in CI

The real value comes from wiring this into your deployment pipeline. There's a GitHub Action that does this automatically on every push to main:

# .github/workflows/docs.yml
name: Auto-generate docs

on:
  push:
    branches: [main]

jobs:
  docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: peaklineops/code-docs-action@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          rapidapi_key: ${{ secrets.RAPIDAPI_KEY }}
          repo_url: "https://github.com/${{ github.repository }}"
          doc_type: full
          output_file: README.md

Every merge to main triggers a fresh README. The Action auto-commits the updated file back to the repo.

What the generated docs look like

For a typical REST API project, the output includes:

Project overview — what the service does, who it's for
Prerequisites and installation — inferred from package.json, requirements.txt, etc.
Endpoint reference — routes detected from the codebase, with request/response examples
Authentication — detected from auth middleware patterns
Error codes — inferred from error handling logic
Examples — working code samples in multiple languages

It won't replace hand-crafted narrative documentation for complex systems, but it's an excellent baseline that's always synchronized with the current code.

Getting started

The API is available on RapidAPI with a free tier (5 requests/day, no credit card required):

Subscribe on RapidAPI
Grab your API key from the RapidAPI dashboard
Make your first call with the curl above
Set up the GitHub Action for continuous generation

What do you use for keeping docs in sync with your codebase? Curious if anyone has found a better workflow.

Stop Writing README Files by Hand: Auto-Generate API Docs on Every Merge

Peakline Studio — Mon, 30 Mar 2026 01:32:27 +0000

Every engineering team has the same README problem.

Someone writes a great README when the project launches. Six months later, the API has changed in three places but the docs haven't. New developers onboard with incorrect examples. API consumers hit endpoints that no longer exist. And nobody wants to be the person who has to sit down and manually rewrite the documentation.

The traditional answer is "just update the docs when you change the code." The actual behavior is: docs drift.

There's a better approach: treat documentation as a build artifact, not a manual deliverable.

The Pattern: Docs as CI Output

The same way you run tests on every PR and generate coverage reports on every merge, you can generate documentation automatically. The key insight is that your codebase already contains everything needed to produce accurate docs — function signatures, module structure, exports, route handlers. An AI model can read that structure and produce documentation that reflects what the code actually does, not what someone wrote about it six months ago.

Here's how to wire this up in a GitHub Actions workflow.

Setup: Two Files, Five Minutes

You'll need a RapidAPI key with access to the Code Documentation Generator API. The free tier handles small repos comfortably.

Step 1: Add your RapidAPI key as a secret

In your repo: Settings → Secrets and variables → Actions → New repository secret

Name: RAPID_API_KEY

Step 2: Create .github/workflows/docs.yml

name: Generate Documentation

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  generate-docs:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - uses: actions/checkout@v4

      - name: Generate full documentation
        uses: peaklineops/code-docs-action@v1
        with:
          repo_url: https://github.com/${{ github.repository }}
          doc_type: full
          output_file: docs/API.md
          rapid_api_key: ${{ secrets.RAPID_API_KEY }}

      - name: Commit updated docs
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add docs/API.md
          git diff --staged --quiet || git commit -m "docs: auto-update API documentation [skip ci]"
          git push

That's it. Every time you push to main, the action:

Fetches your repo's source files
Sends them to the documentation API
Gets back structured markdown docs
Commits the result back to your repo

The [skip ci] tag prevents the commit from triggering another docs run.

Three Doc Types

The action supports three modes via the doc_type parameter:

readme — Generates a full project README: what it does, installation, usage, examples. Good for public repos where the README is the first thing people read.

api-reference — Generates a structured API reference: all endpoints/functions with parameters, return types, and examples. Good for libraries and REST APIs.

full — Combines both. A complete README plus detailed API reference in a single document.

Selective Documentation

If you only want to regenerate docs when source files change (not on every push), use path filtering:

on:
  push:
    branches: [main]
    paths:
      - 'src/**'
      - 'lib/**'
      - '*.ts'
      - '*.js'
      - '*.py'

This skips the doc generation step when only tests, config files, or existing docs change — no unnecessary API calls.

Splitting README from API Reference

For larger projects, you may want to keep your README human-authored (for tone and positioning) but auto-generate the technical API reference:

    steps:
      - uses: actions/checkout@v4

      - name: Generate API reference only
        uses: peaklineops/code-docs-action@v1
        with:
          repo_url: https://github.com/${{ github.repository }}
          doc_type: api-reference
          output_file: docs/API_REFERENCE.md
          rapid_api_key: ${{ secrets.RAPID_API_KEY }}

This gives you a consistently-updated docs/API_REFERENCE.md while leaving your README.md under human control.

The Result

After the first run, you'll have a docs/API.md (or wherever you pointed output_file) that reflects the current state of your codebase. It updates automatically on every merge to main. New team members get accurate docs on day one. API consumers don't hit deprecated endpoints.

The documentation debt stops accumulating.

The Code Documentation Generator API is available on RapidAPI. The GitHub Action is at peaklineops/code-docs-action. Free tier: 5 requests/day. Pro: $9/mo for 100 requests/day.

Debug GitHub Actions Webhooks Without ngrok

Peakline Studio — Mon, 30 Mar 2026 01:23:32 +0000

If you've ever tried to debug a webhook integration inside a GitHub Actions workflow, you know the pain.

Your CI pipeline fires a webhook to an external service. Something goes wrong. You have no idea what payload actually got sent — GitHub's UI shows you the trigger, not what your workflow delivered downstream.

The usual answer is ngrok: spin up a tunnel, expose a local server, redirect your webhook, inspect it manually. It works, but it's tedious, stateful, and dies the moment your laptop sleeps.

There's a better way.

The Problem in Detail

Say you have a workflow like this:

name: Notify on Deploy
on:
  push:
    branches: [main]

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Send deploy webhook
        run: |
          curl -X POST ${{ secrets.WEBHOOK_URL }} \
            -H "Content-Type: application/json" \
            -d '{"ref": "${{ github.ref }}", "sha": "${{ github.sha }}", "actor": "${{ github.actor }}"}'

When this breaks, you want to see the exact payload that was sent — headers, body, response code. But:

GitHub shows you workflow logs, not what the receiving server saw
If your target URL is broken or returns a 500, you can't see what it received
Replay is impossible without re-triggering the whole pipeline

Using a Webhook Inspection Endpoint

HookTest lets you create a disposable HTTPS endpoint that captures every request — headers, body, method, timestamp. No install, no local server, no tunnels.

Here's how to wire it into the workflow above:

Step 1: Create a test endpoint

curl -X POST https://hooktest.peakline-ops.workers.dev/api/endpoints \
  -H "Content-Type: application/json" \
  -d '{"label": "github-actions-debug"}'

Response:

{
  "id": "abc123",
  "url": "https://hooktest.peakline-ops.workers.dev/w/abc123",
  "label": "github-actions-debug"
}

Step 2: Point your test run at it

Temporarily swap your WEBHOOK_URL secret for the HookTest endpoint URL, or add a parallel debug step:

      - name: Debug webhook payload
        if: env.DEBUG_WEBHOOKS == 'true'
        run: |
          curl -X POST https://hooktest.peakline-ops.workers.dev/w/abc123 \
            -H "Content-Type: application/json" \
            -H "X-GitHub-Run-ID: ${{ github.run_id }}" \
            -d '{"ref": "${{ github.ref }}", "sha": "${{ github.sha }}", "actor": "${{ github.actor }}"}'

Set DEBUG_WEBHOOKS=true as a repo variable when debugging, false in production. Zero secrets exposed.

Step 3: Inspect the captured request

curl https://hooktest.peakline-ops.workers.dev/api/endpoints/abc123/requests

You'll get back everything:

[
  {
    "id": "req_xyz",
    "method": "POST",
    "headers": {
      "content-type": "application/json",
      "x-github-run-id": "12345678"
    },
    "body": "{\"ref\":\"refs/heads/main\",\"sha\":\"a1b2c3d4\",\"actor\":\"octocat\"}",
    "captured_at": "2026-03-29T10:23:45Z"
  }
]

Step 4: Replay to the real target when ready

curl -X POST https://hooktest.peakline-ops.workers.dev/api/requests/req_xyz/replay \
  -H "Content-Type: application/json" \
  -d '{"target_url": "https://your-real-service.com/webhook"}'

Replay lets you test your receiving service without re-triggering the entire CI pipeline.

Dashboard View

If you prefer a visual interface, the HookTest dashboard gives you a real-time view of all captured requests with full header and body inspection. No account required for the free tier.

Pro Tips for CI/CD Webhook Debugging

1. Add a GitHub run ID header to every webhook

Always include X-GitHub-Run-ID: ${{ github.run_id }} in your outgoing webhooks. This lets you correlate captured payloads back to specific pipeline runs in the GitHub UI.

2. Test the receiving service in isolation

Capture your payload once with HookTest, then replay it repeatedly against your service as you iterate — no need to keep pushing commits.

3. Use transform rules to sanitize before forwarding

HookTest's Pro tier supports transform rules: mask sensitive fields (like tokens), rename fields for compatibility, or filter out requests by header value. Useful when your payload contains secrets you don't want stored in plain text.

4. Temporary endpoints are free

Free tier endpoints auto-expire after 24 hours. For debugging a CI pipeline, that's usually enough. Pro endpoints persist indefinitely, which is useful for long-running test environments.

Why Not Just Log the Payload in the Workflow?

You can — and you should — add echo statements or cat the payload in your workflow logs. But that only shows you what you sent. It doesn't show you what your receiving server saw (after any proxies, load balancers, or CDN rewrites), what headers arrived, or how the response looked. An inspection endpoint captures the full inbound request as the server sees it.

HookTest is free to use at hooktest.peakline-ops.workers.dev. Free tier: 3 endpoints, 24-hour expiry, 100 requests per endpoint. Pro ($9/mo): 10 persistent endpoints, transform rules, unlimited requests.

Happy debugging.

Keep Your GitHub Repo Docs Always Up-to-Date with This Free GitHub Action

Peakline Studio — Sun, 29 Mar 2026 16:41:37 +0000

We've all been there: you ship a feature, update the code, and then... the README still describes the old behavior. Three weeks later someone files an issue asking why the docs don't match. You fix the docs, ship another feature, and the cycle repeats.

Documentation drift is a solved problem — if you automate it.

In this tutorial I'll walk you through setting up a GitHub Action that automatically regenerates your README (or full API docs) every time you push to main. Zero config, one YAML file, done.

How It Works

The code-docs-action calls the Code Documentation Generator API on every push. The API analyzes your repository's source files using Claude AI and returns structured markdown documentation. The action then writes it to your target file and commits it back.

The API has a free tier (5 scans/month) — plenty for a side project with infrequent pushes, or for testing before upgrading.

Step 1: Get a Free RapidAPI Key

Step 2: Add the Secret to Your Repo

In your GitHub repository:

Go to Settings → Secrets and variables → Actions
Click New repository secret
Name: RAPIDAPI_KEY
Value: your RapidAPI key

Step 3: Create the Workflow File

Create .github/workflows/docs.yml in your repo:

name: Auto-generate documentation

on:
  push:
    branches: [main]
  workflow_dispatch:  # lets you trigger manually too

jobs:
  generate-docs:
    runs-on: ubuntu-latest
    permissions:
      contents: write  # needed to commit back to repo
    steps:
      - uses: actions/checkout@v4

      - name: Generate README
        uses: peaklineops/code-docs-action@v1.1
        with:
          rapidapi-key: ${{ secrets.RAPIDAPI_KEY }}
          doc-type: readme        # or "full" or "api-reference"
          output-file: README.md

Commit and push — the action runs immediately.

What Gets Generated

The API reads your source files (ignoring node_modules, build artifacts, etc.) and generates documentation tailored to your codebase. For a typical project you'll get:

Project overview — what the project does, based on code structure
Installation instructions — inferred from package.json, pyproject.toml, etc.
Usage examples — based on exported functions and public APIs
API reference — for libraries, a full table of exports with descriptions

Configuration Options

The action has several inputs:

Input	Default	Description
`doc-type`	`readme`	`readme`, `api-reference`, or `full`
`output-file`	`README.md`	Where to write the output
`commit-docs`	`true`	Set `false` to just write the file (useful in PR checks)
`commit-message`	`docs: auto-update documentation [skip ci]`	The commit message

Generating API Docs Separately

If you want a separate API reference file in addition to your README:

steps:
  - uses: actions/checkout@v4

  - name: Generate README
    uses: peaklineops/code-docs-action@v1.1
    with:
      rapidapi-key: ${{ secrets.RAPIDAPI_KEY }}
      doc-type: readme
      output-file: README.md

  - name: Generate API Reference
    uses: peaklineops/code-docs-action@v1.1
    with:
      rapidapi-key: ${{ secrets.RAPIDAPI_KEY }}
      doc-type: api-reference
      output-file: docs/API.md

Tip: Run on PRs Without Committing

For pull requests, you might want to preview generated docs without auto-committing:

on:
  pull_request:

jobs:
  preview-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Preview docs changes
        uses: peaklineops/code-docs-action@v1.1
        with:
          rapidapi-key: ${{ secrets.RAPIDAPI_KEY }}
          commit-docs: "false"   # generate only, don't commit

      - name: Show diff
        run: git diff README.md

This lets reviewers see exactly how the docs will change before merging.

Wrapping Up

Once this is set up, documentation becomes a side effect of shipping code rather than a separate task. Your README reflects the current state of the codebase, always.

The action is open source: peaklineops/code-docs-action. Issues and PRs welcome.

The underlying API is on RapidAPI: Code Documentation Generator — free tier available, no credit card required.

How to Filter, Mask, and Route Stripe Webhooks Without Writing Code

Peakline Studio — Sun, 29 Mar 2026 16:21:16 +0000

If you've ever built a Stripe integration, you know the pain: every webhook event hits your endpoint — even the ones you don't care about. charge.updated flooding your logs while you're only watching for payment_intent.succeeded. Sensitive card metadata sitting in plain text in your inspection logs. Fields named one thing in Stripe but something different in your database schema.

Normally, solving this means writing middleware. A filter here, a field mask there, a rename transformer somewhere else. It's boilerplate — but it has to be written, tested, and maintained.

I built a small feature into HookTest (a webhook testing and inspection tool) called Transform Rules that handles all three cases without writing any code.

What Transform Rules Do

When a webhook hits your HookTest endpoint, before the request is stored, you can apply a chain of rules in order:

Filter — only capture requests where a JSON field matches a condition (equals, contains, starts with). Anything that doesn't match is acknowledged with 200 OK but silently dropped.
Mask — replace a sensitive field value with a placeholder (*** by default). The payload is stored with the masked value — the original never touches disk.
Rename — rename a JSON key before storage (e.g., user_id → userId).

Rules run in the order you define them. Filter rules always run first (even if you add them later), so a dropped request never gets transformed.

A Real Example: Filtering Stripe Events

Say you're testing a checkout flow and you only want to see checkout.session.completed events — nothing else.

Create a HookTest endpoint and copy the URL into your Stripe webhook dashboard.
Open the "Transform Rules" tab on your endpoint.
Add a Filter rule: path = type, operator = eq, value = checkout.session.completed.

Now when Stripe fires payment_intent.created, charge.updated, or any other event, HookTest acknowledges it silently. Your inspection log stays clean.

// Only this gets stored:
{
  "type": "checkout.session.completed",
  "data": { "object": { "id": "cs_test_..." } }
}

// Everything else → acknowledged but dropped

Masking Sensitive Data

Stripe payloads can contain customer emails, card last-four digits, billing addresses. If you're sharing your HookTest endpoint URL with a teammate to debug something, you probably don't want that data in the captured log.

Add a Mask rule: path = data.object.customer_details.email, mask = [REDACTED].

The stored payload looks like:

{
  "data": {
    "object": {
      "customer_details": {
        "email": "[REDACTED]",
        "name": "Jane Smith"
      }
    }
  }
}

The raw email never gets written to storage.

Why Not Just Write a Filter in Your App?

You can — but there's a catch. When you're testing, you want to inspect what Stripe is actually sending before your app logic runs. If your filter middleware drops the event, you've lost visibility into the raw payload.

HookTest sits upstream of your app. It captures first, applies your rules, then you can see exactly what would have been stored — and replay it to your real endpoint when you're ready.

The replay feature is especially useful here: capture once, inspect, then fire it at http://localhost:3000/webhooks as many times as you need.

Availability

Transform Rules are a Pro feature ($9/mo). Free tier gets unlimited basic capture and inspection with no rules.

If you're testing Stripe, GitHub, Twilio, or any other webhook source, give HookTest a try — the free tier should cover most debugging sessions.

HookTest is built on Cloudflare Workers + D1 with a zero-dependency dashboard. The transform rule engine is ~120 lines of TypeScript.

How to Test Stripe Webhooks Without Deploying Code

Peakline Studio — Sat, 28 Mar 2026 17:22:29 +0000

You're integrating Stripe. You need to handle payment_intent.succeeded. Before you write a single line of handler code, you need to know exactly what Stripe sends.

The classic approach:

Deploy a temporary endpoint with logging
Configure it in Stripe Dashboard
Trigger a test event
Dig through logs
Tweak your code, repeat

That's 15 minutes of plumbing before you write any real logic. Every time you need to check a different event type, you do it again.

There's a better way.

The fast approach: use a webhook inspector

A webhook inspector gives you an instant HTTPS URL. Point your webhook provider at it, trigger an event, and see the full payload — headers, body, timing — immediately in your browser. No deploy, no logging setup, no waiting.

For this walkthrough I'll use HookTest — a free tool I built for exactly this workflow. No account required.

Step 1: Get your endpoint URL

Open HookTest and click New Endpoint. You'll get a URL like:

https://hooktest.peakline-ops.workers.dev/w/abc123xyz

That's it. Your endpoint is live.

Step 2: Add it to Stripe

Go to Stripe Dashboard → Developers → Webhooks
Click Add endpoint
Paste your HookTest URL
Select the events you care about — or just pick All events for exploration
Click Add endpoint

Now trigger a test event. In Stripe, find the webhook you just created and click Send test webhook. Pick payment_intent.succeeded.

Step 3: See what Stripe actually sends

Switch back to HookTest. The request appears immediately:

POST /w/abc123xyz
stripe-signature: t=1711641600,v1=3c5d8f...
content-type: application/json

{
  "id": "evt_3OqABC2eZvKYlo2C1711641600",
  "object": "event",
  "api_version": "2024-04-10",
  "created": 1711641600,
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_3OqABC2eZvKYlo2C1711641600",
      "object": "payment_intent",
      "amount": 2999,
      "amount_received": 2999,
      "currency": "usd",
      "status": "succeeded",
      "customer": "cus_ABC123",
      "metadata": {},
      "payment_method": "pm_1OqABC2eZvKYlo2C..."
    }
  },
  "livemode": false
}

Now you know exactly what fields exist and what types they are. Write your handler with confidence.

Step 4: Replay to your local dev server

Once your handler is written and running on localhost:3000, you don't need to re-trigger the event in Stripe. Click Replay on the captured request, enter your local URL:

http://localhost:3000/webhooks/stripe

HookTest re-sends the exact payload with all original headers — including the Stripe-Signature header. Your local handler sees a real request.

This is the part that saves the most time. Iterate on your handler by replaying the same payload over and over, without touching Stripe each time.

What about ngrok?

ngrok tunnels traffic to your local server — useful when you want Stripe to hit localhost directly. But that means your server needs to be running and accessible before you can see anything.

Webhook inspection flips this: capture first, understand the payload, then write the handler. Use both tools for different stages:

Stage	Tool
Exploring payload structure	HookTest (inspect)
Iterating on your handler	HookTest (replay)
End-to-end integration test	ngrok / `stripe listen`

Stripe-specific tips

Verify signatures in your handler. Every Stripe webhook includes a Stripe-Signature header. Your handler should validate it:

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];

  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  switch (event.type) {
    case 'payment_intent.succeeded':
      const paymentIntent = event.data.object;
      // fulfill order
      break;
  }

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

Note: When replaying from HookTest, the signature won't verify unless you disable signature checking in dev mode — that's fine for development. In production, always verify.

Watch for event versions. Stripe sends api_version in every event. If your Stripe account is on a different API version than what you're testing, the payload shape can differ. Check this in your Stripe Dashboard under Developers → API keys.

Other webhook providers

This exact workflow works with any webhook-based API:

Provider	Where to configure	Test event trigger
GitHub	Settings → Webhooks	"Redeliver" button
Shopify	Partners → App → Webhooks	Test notification
Twilio	Console → Phone Numbers	Use ngrok + real SMS
Slack	App config → Event Subscriptions	Slash command or action
SendGrid	Settings → Mail Settings → Event Webhook	Send a test email

Summary

The next time you need to integrate a webhook:

Open HookTest → get an endpoint URL (5 seconds, no account)
Paste it into your provider's webhook config
Trigger a test event → see the full payload immediately
Write your handler with real field names and types
Replay from HookTest → iterate without re-triggering the source

No deploy cycle. No log parsing. No guessing.

Try HookTest free →

Built HookTest because I was tired of re-deploying logging endpoints every time I integrated a new webhook provider. The free tier is genuinely useful — no account, no credit card, 100 requests before anything expires.

How I Built an AI That Generates README Files and API Docs from Any GitHub Repo

Peakline Studio — Sat, 28 Mar 2026 15:31:59 +0000

Every developer has been there: you've built something great, but writing the documentation feels like a second project. README files go stale, API references never get written, and onboarding new contributors is painful.

I built Code Documentation Generator to solve this — a single POST request that returns production-ready Markdown documentation for any public GitHub repo.

What it does

Send a GitHub repo URL, get back structured Markdown documentation. That's it.

Three output formats:

Full documentation — README + API reference + usage examples, all in one
README only — project overview, installation, usage, contributing guide
API reference — every function/class/method documented with parameters and return types

It uses Claude AI under the hood to actually understand your code, not just parse it. So the output reads like a human wrote it.

The API (one request)

curl -X POST https://code-docs-api.peakline-ops.workers.dev/v1/generate \
  -H "Content-Type: application/json" \
  -d '{
    "repo_url": "https://github.com/your-org/your-repo",
    "ref": "main"
  }'

Response:

{
  "ok": true,
  "format": "full",
  "repo": "your-org/your-repo",
  "ref": "main",
  "documentation": "# Your Project\n\n..."
}

That's the entire integration. Pipe the documentation field wherever you need it — your wiki, your CMS, a GitHub Action that commits docs on every push.

How it works under the hood

Fetches the repo tree from GitHub's API
Reads source files (filtering out node_modules, build artifacts, etc.)
Sends code + structure to Claude Sonnet with a format-specific prompt
Returns structured Markdown

Everything runs on Cloudflare Workers — globally distributed, sub-100ms cold starts, no servers to maintain.

Results are cached in D1 (Cloudflare's edge SQLite) for 24 hours, so repeated requests for the same repo/ref are instant.

Use cases I've seen

Keep docs in sync with code — run it in CI on every merge to main, commit the output to your repo. No more stale READMEs.

Onboard contributors faster — new devs can generate up-to-date docs for any unfamiliar module before diving in.

Document OSS dependencies — sometimes a library you depend on has terrible docs. Generate your own.

API documentation for internal tools — your company's internal utilities deserve docs too.

Available on RapidAPI

The API is now listed on RapidAPI: Code Documentation Generator

Free tier: 5 requests/month to try it out
Pro ($9/mo): for regular use
Ultra ($29/mo): for teams and CI pipelines

Direct link: https://rapidapi.com/peaklineops/api/code-documentation-generator

Or hit the endpoint directly — no account needed for the free tier (IP-based, 5 requests/month).

What's next

GitHub Action wrapper (document your repo on every push with zero config)
Support for private repos via GitHub token
Webhook trigger (push to a branch → docs auto-update)

Would love feedback from anyone who tries it. What formats are most useful? What's missing?

Built with Cloudflare Workers + D1 + Claude API. Stack is ~300 lines of TypeScript.