Capturez toute requête HTTP,
sans monter de serveur.
Créez un bin et obtenez une URL publique sur nnbin.net. Pointez-y n’importe quoi : votre propre app, un script, un job de CI, un appareil, un fournisseur de webhooks. Chaque requête reçoit aussitôt un 200 et est enregistrée avec sa méthode, son chemin, sa query, ses en-têtes, son corps et son adresse source, prête à lire dans la console ou via l’API.
Quatre étapes, et rien à déployer.
Un bin, c’est une URL et une liste. Tout ce qui arrive sur l’URL entre dans la liste, la plus récente en tête, jusqu’à ce que la fenêtre de rétention l’efface.
Créez un bin
Un clic dans la console, ou un appel d’API, renvoie une URL comme https://nnbin.net/b/k7m2q9x4r8ht. Le slug porte 60 bits d’aléa et n’est jamais réattribué, même après la suppression du bin.
Pointez-y un émetteur
Collez l’URL partout où l’on vous demande un endpoint : dans les réglages webhooks d’un fournisseur, comme URL de base de l’API de votre app, dans un script, dans une étape de CI. N’importe quelle méthode, n’importe quel chemin sous le bin, n’importe quel corps.
Il répond aussitôt
Toute requête bien formée reçoit immédiatement un 200 avec {"status":"accepted"}, si bien que l’émetteur continue comme si un vrai endpoint l’avait acceptée. Un bin ne transmet, ne rejoue et n’exécute jamais rien de ce qu’il reçoit.
Lisez ce qui est arrivé
La console liste les requêtes au fil de leur arrivée, avec les en-têtes dans l’ordre d’arrivée et le corps mis en forme pour la lecture. Avec un plan payant, une clé API lit les mêmes requêtes depuis votre code.
Un bin désactivé, ou qui a dépassé le quota du mois, répond toujours 200 et n’enregistre rien. Un émetteur qui envoie plus vite que la limite de débit reçoit un 429, et celui dont la requête ne peut pas être enregistrée sur le moment reçoit un 503, pour qu’il réessaie.
La requête telle qu’elle est arrivée, pas telle qu’on voulait l’envoyer.
La documentation montre ce qu’un émetteur est censé envoyer. Un bin montre ce qu’il a réellement envoyé, jusqu’à l’ordre de ses en-têtes et la taille de son corps.
Toute méthode, tout chemin
GET, POST, PUT, PATCH, DELETE, HEAD et OPTIONS, sur l’URL du bin et sur tout chemin en dessous, si bien qu’un émetteur qui ajoute son propre chemin arrive quand même.
En-têtes dans l’ordre d’arrivée
Tels que l’émetteur les a écrits, en-têtes répétés compris. Authorization, Proxy-Authorization, Cookie, Set-Cookie et X-Api-Key sont conservés par leur nom, avec la valeur masquée.
Le corps et sa taille réelle
Jusqu’à 64 KiB de chaque corps sont stockés, avec la taille réellement envoyée et un indicateur quand la copie stockée est tronquée.
Query, provenance et heure
La query telle qu’elle a été envoyée, l’adresse d’où vient la requête, son type de contenu et l’instant de son arrivée.
Des corps lisibles
Le JSON est mis en forme, les envois de formulaire s’affichent en champs et un corps qui n’est pas du texte s’affiche en vidage hexadécimal. Le corps brut est à un clic, et rien n’est jamais rendu comme une page web.
Répétitions comptées une fois
Une requête de même méthode, même chemin et même corps qu’une requête déjà conservée est comptée sur cette entrée au lieu d’être stockée à nouveau. C’est à cela que ressemblent les réessais d’un émetteur.
Des URL jamais réutilisées
Un slug est retiré pour de bon quand son bin est supprimé : rien de ce qui était destiné à un ancien bin ne peut atterrir dans un nouveau.
Privé à votre espace de travail
Les bins et ce qu’ils enregistrent appartiennent à l’espace de travail qui les a créés, et la base de données l’impose à chaque requête SQL.
Envoyez n’importe quoi. Relisez-le tel quel.
La première requête est ce que fait votre émetteur. La seconde est la façon dont un test ou un script la relit avec une clé API, sur n’importe quel plan payant.
# Tout émetteur, toute méthode, tout chemin sous le 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"}
# Relire la requête avec une clé API
curl -H "Authorization: Bearer $BINS_API_KEY" \
"https://bins.nimbusnexus.net/v1/bins/$BIN_ID/requests"{
"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
}Tout ce qui émet une requête HTTP. C’est là qu’il est le plus utile.
Remplacez une URL de base d’API par un bin et exécutez le chemin de code. Les en-têtes ajoutés par votre client HTTP, le corps produit par votre sérialiseur et la query que vous avez construite sont tous là, tels qu’ils ont quitté le processus.
Avant d’écrire le handler, donnez au fournisseur l’URL d’un bin et déclenchez un événement. Vous voyez exactement le corps, les en-têtes et la signature qu’il envoie, pas l’exemple de sa documentation.
Pointez un backfill, une tâche cron ou une migration ponctuelle vers un bin avant qu’ils ne touchent le vrai endpoint, et lisez chaque requête qu’ils auraient envoyée.
Les hooks de déploiement, les notifications de release et les callbacks de build partent de runners de CI que personne ne surveille. Envoyez-les vers un bin et lisez-les après l’exécution.
Les apps mobiles, les appareils et les outils en ligne de commande envoient des requêtes que vous ne pouvez pas suivre au débogueur. Donnez-leur l’URL d’un bin et voyez ce qu’ils envoient, depuis le réseau où ils se trouvent.
Avec un plan payant, un test envoie par le vrai chemin de code, puis lit le bin via l’API et vérifie la méthode, les en-têtes et le corps que le code a produits.
Gratuit pour commencer, payant pour plus de requêtes et d’historique.
Chaque plan répond à tout émetteur et se lit dans la console. Un plan payant enregistre plus de requêtes par mois, accueille plus de bins, conserve les requêtes plus longtemps et permet à une clé API de les lire.
Free
Assez pour voir exactement ce qu’envoie une app, un script ou un service.
$0
- 1,000 requêtes / mois
- 1 bin
- Requêtes conservées 1 jour
- Un bin dure 24 heures
- Pas de lecture des requêtes capturées par clé API
Starter
Pour déboguer des intégrations pendant que vous les construisez.
$9/ mois
$86.40 / an — 20 % d’économie
- 25,000 requêtes / mois
- 5 bins
- Requêtes conservées 7 jours
- Lecture des requêtes capturées par clé API
Pro
Plus de bins, plus d’historique, de la place pour toute une équipe.
$29/ mois
$278.40 / an — 20 % d’économie
- 250,000 requêtes / mois
- 25 bins
- Requêtes conservées 30 jours
- Lecture des requêtes capturées par clé API
Custom
Engagements de volume, limites sur mesure et conditions adaptées.
Sur devis
- Nombre de bins convenu avec vous
- Volume de requêtes convenu avec vous
- Historique des requêtes convenu avec vous
- Nécessite un compte d’équipe
Chaque requête enregistrée par un bin compte pour le mois, répétitions comprises. Au-delà du quota mensuel, un bin répond toujours 200 et n’enregistre rien jusqu’au 1er du mois suivant ; sur un plan payant, aucun bin ne peut à lui seul consommer tout le quota, si bien qu’une URL qui a fuité ne peut pas l’épuiser pour les autres. La formule annuelle est facturée une fois par an avec 20 % de remise.
- Toute méthode, tout chemin, tout corps
- Un 200 immédiat pour chaque émetteur
- En-têtes dans l’ordre d’arrivée
- En-têtes d’identification masqués
- Corps mis en forme et bruts
- Répétitions comptées une fois
- Slugs jamais réutilisés
- Isolation par espace de travail
Avant de pointer quoi que ce soit vers un bin.
À voir aussi
Où aller ensuite
Pointez quelque chose vers un bin et voyez ce qu’il envoie.
Free comprend un bin et 1,000 requêtes enregistrées par mois, à lire dans la console. Passez à un plan payant quand il vous faut plus de bins, plus d’historique ou la lecture par clé API.