Skip to content
NimbusNexus
Request Bins · For any HTTP sender

Catch any HTTP request,
without standing up a server.

Create a bin and get a public URL on nnbin.net. Point anything at it: your own app, a script, a CI job, a device, a webhook provider. Each request is answered at once with a 200 and recorded with its method, path, query, headers, body and source address, ready to read in the console or over the API.

How it works

Four steps, and nothing to deploy.

A bin is a URL and a list. Whatever reaches the URL lands in the list, newest first, until the retention window removes it.

  1. Create a bin

    One click in the console, or one API call, returns a URL such as https://nnbin.net/b/k7m2q9x4r8ht. The slug carries 60 bits of randomness and is never issued again, even after the bin is deleted.

  2. Point a sender at it

    Paste the URL wherever something asks for an endpoint: a provider’s webhook settings, your app’s API base URL, a script, a CI step. Any method, any path beneath the bin, any body.

  3. It answers at once

    Every well-formed request gets 200 with {"status":"accepted"} straight away, so the sender carries on as if a real endpoint had taken it. A bin never forwards, replays or runs anything it receives.

  4. Read what arrived

    The console lists requests as they land, with the headers in arrival order and the body formatted for reading. On a paid plan, an API key reads the same requests from code.

A disabled bin, or one past the month’s allowance, still answers 200 and records nothing. A sender that sends faster than the rate limit gets 429, and one whose request cannot be recorded right now gets 503, so that it retries.

What a bin records

The request as it arrived, not as anyone meant to send it.

Documentation shows what a sender is supposed to send. A bin shows what it actually sent, down to the order of its headers and the size of its body.

Every method, every path

GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS, on the bin’s URL and on any path beneath it, so a sender that appends its own path still lands.

Headers in arrival order

Kept as the sender wrote them, repeated headers included. Authorization, Proxy-Authorization, Cookie, Set-Cookie and X-Api-Key are kept by name, with the value redacted.

The body, and its real size

Up to 64 KiB of every body is stored, with the size that was actually sent and a flag when the stored copy is cut short.

Query, source and time

The query string as it was sent, the address the request came from, its content type and the moment it arrived.

Bodies you can read

JSON is formatted, form posts are shown as fields, and a body that is not text is shown as a hex dump. The raw body is one click away, and nothing is ever rendered as a web page.

Repeats counted once

A request with the same method, path and body as one the bin already holds is counted on that entry instead of being stored again. That is what a sender’s retries look like.

URLs that are never reused

A slug is retired for good when its bin is deleted, so nothing meant for an old bin can land in a new one.

Private to your workspace

Bins and what they record belong to the workspace that created them, and the database enforces it on every query.

In two requests

Send anything. Read back exactly that.

The first request is whatever your sender does. The second is how a test or a script reads it back with an API key, on any paid plan.

# Any sender, any method, any path beneath the bin
curl -X POST "https://nnbin.net/b/k7m2q9x4r8ht/orders?source=checkout" \
  -H "Content-Type: application/json" \
  -d '{"order":"ord_1042","total":4900}'
# → 200 {"status":"accepted"}

# Read it back with an API key
curl -H "Authorization: Bearer $BINS_API_KEY" \
  "https://bins.nimbusnexus.net/v1/bins/$BIN_ID/requests"
Response
{
  "items": [{
    "id": "req_3f9a61c0d2e84b7a95c1e6d0",
    "bin_id": "bin_8e27d40b19c3f6a5e0d71b42",
    "method": "POST",
    "path": "/orders",
    "source_ip": "203.0.113.24",
    "content_type": "application/json",
    "size_bytes": 33,
    "truncated": false,
    "seen_count": 1,
    "received_at": "2026-11-03T09:14:07Z",
    "expires_at": "2026-11-10T09:14:07Z"
  }],
  "next_offset": null
}
Who sends to a bin

Anything that makes an HTTP request. These are where it helps most.

YOUR OWN CODE
See what your app really sends

Swap an API base URL for a bin and run the code path. The headers your HTTP client adds, the body your serialiser produced and the query string you built are all there, as they left the process.

API_BASE_URL=https://nnbin.net/b/k7m2q9x4r8ht
THIRD-PARTY SENDERS
Read a provider’s real payload

Before you write the handler, give the provider a bin’s URL and trigger an event. You see the exact body, headers and signature it sends, not the sample in its documentation.

POST /b/k7m2q9x4r8ht/events · x-signature: t=…,v1=…
SCRIPTS AND JOBS
Dry-run a script

Point a backfill, a cron job or a one-off migration at a bin before it touches the real endpoint, and read every request it would have made.

PUT /b/k7m2q9x4r8ht/customers/42 → 200 {"status":"accepted"}
CI PIPELINES
Catch what a pipeline posts

Deploy hooks, release notices and build callbacks fire from CI runners nobody is watching. Send them to a bin and read them after the run.

POST /b/k7m2q9x4r8ht/deploys · source_ip 198.51.100.7
DEVICES AND CLIENTS
Clients you did not write

Mobile apps, devices and command-line tools send requests you cannot step through. Give them a bin’s URL and see what they send, from whatever network they are on.

POST /b/k7m2q9x4r8ht/telemetry · {"fw":"2.4.1"}
INTEGRATION TESTS
Assert on outgoing requests

On a paid plan, a test sends through the real code path, then reads the bin over the API and checks the method, headers and body the code produced.

GET /v1/bins/{id}/requests?since=…
Plans

Free to start, paid for more requests and longer history.

Every plan answers every sender and reads in the console. A paid plan records more requests a month, holds more bins, keeps requests longer and lets an API key read them.

Free

Enough to see exactly what any app, script or service sends.

$0

  • 1,000 requests / month
  • 1 bin
  • Requests kept for 1 day
  • A bin lasts 24 hours
  • No API-key reads of captured requests
Get started

Starter

For debugging integrations as you build them.

$9/ month

$86.40 / year — save 20%

  • 25,000 requests / month
  • 5 bins
  • Requests kept for 7 days
  • API-key reads of captured requests
Choose Starter

Pro

More bins, longer history, room for a whole team.

$29/ month

$278.40 / year — save 20%

  • 250,000 requests / month
  • 25 bins
  • Requests kept for 30 days
  • API-key reads of captured requests
Choose Pro

Custom

Volume commitments, bespoke limits, and terms to match.

Contract priced

  • Bins agreed with you
  • Request volume agreed with you
  • Request history agreed with you
  • Requires a team account
Talk to us

Every request a bin records counts toward the month, repeats included. Past the monthly allowance a bin still answers 200 and records nothing until the 1st of the next month, and on a paid plan no single bin can use the whole allowance, so one leaked URL cannot use it up for the others. The annual term is billed once a year at 20% off.

On every plan, Free included
  • Any method, any path, any body
  • An immediate 200 for every sender
  • Headers kept in arrival order
  • Credential headers redacted
  • Formatted and raw bodies
  • Repeats counted once
  • Slugs never reused
  • Isolated per workspace
Questions

Before you point something at a bin.

Anything that makes an HTTP request: webhook providers, your own services, scripts, cron jobs, CI pipelines, mobile apps and devices. A bin accepts GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS on its URL and on any path beneath it, with any body, and records each one the same way whoever sent it.
Get started

Point something at a bin and see what it sends.

Free includes one bin and 1,000 recorded requests a month, read in the console. Move to a paid plan when you need more bins, longer history or reads with an API key.