Request Bins

NimbusNexus Request Bins gives you bins: public URLs that record every HTTP request sent to them, with any method, to any path under the URL, with any body. Point whatever sends HTTP at one — a webhook provider, your own app, a script, a CI job — and read exactly what arrived: the method, path, query, headers, body and the address it came from, in the console or over the REST API.

Not the page you wanted? A bin records what it receives and stops there: it doesn't pass requests on, and it answers every sender the same way. To receive a provider's webhooks and deliver them to your own endpoints, with retries, use a Webhooks source.

At a glance

How it works

1. Create a bin — in the console with New bin, or with POST /v1/bins. Its URL records from that moment.
2. Send it requests. Give the URL to whatever you want to watch — a provider's webhook settings, your app's configuration, a script, a CI job — or curl it yourself. Anything after the slug is yours to choose: a request to https://nnbin.net/b/k7xq2mbn9tfa/orders/42 is recorded with the path /orders/42.
3. Read what arrived. It appears in the console within seconds, and on paid plans at GET /v1/bins/{id}/requests.
4. Delete the bin when you are done, or let it expire.

The quickstart does all four.

Use the url exactly as the API returns it. Bin URLs live on their own domain, nnbin.net, not on nimbusnexus.net.

What a sender gets back

A bin answers every request at once with 200 and the body {"status":"accepted"}, whether it recorded the request or not. A bin that is disabled, suspended or past its plan's monthly requests answers the same way, and so does a URL whose bin never existed or was deleted. That is deliberate: a sender that gets an error may stop sending, or switch your webhook off, and a different answer for a live bin would let anyone probe for bins.

A bin URL answers anything else only when nothing was recorded:

• 429, with Retry-After, when the sender or the bin is over its per-minute limit;
• 503, with Retry-After, when the request couldn't be stored just now, so the sender should send it again;
• 404, when the slug in the URL isn't one Request Bins could ever have issued.

The reference has the details: what a bin URL answers.

What is recorded

For each request, a bin keeps the method, the path after the slug, the query string, the headers in the order they arrived, the body, the address it came from, and when it arrived. A few rules shape what you read back:

• Bodies are stored up to 64 KiB. A larger body keeps its first 64 KiB, truncated is true, and size_bytes still says how large it really was.
• Credentials are redacted. The values of Authorization, Proxy-Authorization, Cookie, Set-Cookie and X-API-Key are replaced with [redacted] before anything is stored. Every other header is kept as sent, signature headers included, since a signature is what you need to see when verifying one fails.
• Nothing is changed or run. A body is stored as the bytes that arrived, and the console shows it as text, never as markup.
• A repeat is one row. A request with the same method, path and body as one the bin already holds adds one to that request's seen_count rather than being stored again, so a sender's retries are counted, not duplicated.

Plans and limits

Free is enough to see exactly what any app, script or service sends: one bin, 1,000 requests a month, read in the console.

The month is a calendar month in UTC, and every request a bin records counts, repeats included. Past the month's requests, bins keep answering 200 and record nothing until the next month begins; requests refused that way don't count. One bin may use only part of the month — all of it on Free, half on Starter, 40% on Pro and a quarter on Custom — so one busy or leaked URL can't use up the requests of the workspace's other bins.

The last two rows are abuse limits, described under Suspended bins.

Suspended bins

A bin URL is public: anyone who has it can send to it. That would make a bin a convenient place to collect what a phishing page's form submits, or data taken from strangers' machines, so a bin is suspended when its traffic looks like that:

• it hears from more distinct addresses than the plan's distinct senders; or
• it receives more form posts from web browsers than the plan's browser form posts, from at least three addresses.

A suspended bin keeps answering 200 and records nothing. The console says why, and so does suspended_code in the API. A suspension is ours, not your switch: enabling the bin doesn't lift it, so contact support if you think one is a mistake. Bins are also held back, without being deleted, when a plan change leaves the workspace more bins than the new plan allows, and while the workspace is suspended for an unpaid charge; each comes back once its cause is resolved.

To report a bin URL that is being abused, write to [email protected] with the full URL.

Getting access

Open the console at https://bins.nimbusnexus.net and sign in with your NimbusNexus account, or add Request Bins from Add a product in any NimbusNexus console. The first visit by a workspace owner or admin adds Request Bins to the workspace; other members can open it from then on. A personal workspace starts on Free, and a team workspace starts with a 7-day Starter trial.

Keys are not issued by the Request Bins API. Create one in your account console under API keys, with Request Bins as the product. A key is a JWT, so it begins eyJ. Present it as Authorization: Bearer <key> or X-API-Key: <key>.

Choose its permission when you create it: Read reads bins and what they recorded, and Read & write can also create, change, empty and delete bins. On Free a key can manage bins, but reading what they recorded over the API needs Starter or above; the console reads it on every plan. Who can do what has the full table, workspace roles included.

What it will not do

• It does not answer with your response. Every bin answers 200 with {"status":"accepted"}; a status, headers or body of your choosing is not built.
• It does not forward. What arrives is recorded, not passed on to another URL, and it can't be replayed.
• It does not push. There is no stream and no callback: poll GET /v1/bins/{id}/requests with since, as the console does every 3 seconds.
• It is not an archive. A request is deleted when the plan's retention runs out, and everything in a bin goes when the bin is deleted or expires.
• It does not split a workspace by project. Request Bins serves whole workspaces, so guest seats and keys limited to one project are refused.

What's next

• Quickstart — create a bin, send it a request, read it back.
• Request Bins reference — every route and field, what a bin URL answers, roles, scopes and limits.
• Request Bins API — every operation, with the request in curl, TypeScript, Python or Go.
• Errors — the error shape and the codes the API sends.