(WEBHOOKS)
En production
POST /v1/relay/eventsRelay
Webhooks‑as‑a‑Service
Livraison fiable des webhooks avec retries automatiques, signatures et portail de gestion complet. Propulsé par Svix.
Infrastructure développeur simplifiée
Webhooks, authentification, connexion Telegram et tâches planifiées – des APIs prêtes pour la production que vous intégrez en quelques minutes, pas en quelques mois.
Sans carte bancaire · Offre gratuite incluse · Feuille de route SOC 2
- WEBHOOKS
- AUTH
- CRON JOBS
- TELEGRAM LOGIN
- API KEYS
- RATE LIMITING
- HMAC SIGNATURES
- IDEMPOTENCY
- RETRIES & BACKOFF
- OIDC
- TOTP MFA
- AUDIT LOGS
- TENANT ISOLATION
- USAGE METERING
(Produits Nautilus)
Une plateforme, toutes vos primitives backend
Nautilus est la plateforme unifiée de Verne Software : une seule API pour tous les moteurs déjà en service comme pour ceux à venir, un tableau de bord unique pour tout piloter, et des SDK officiels pour Node, Python, PHP et Rust. Une infrastructure unique, hébergée dans l'UE, pour les entreprises et les développeurs indépendants européens.
(AUTH)
En production
PATCH /v1/gate/identities/:id/metadataGate
Auth‑as‑a‑Service
Gestion complète des identités B2B – inscription, connexion, récupération et APIs d'administration. Propulsé par Ory Kratos.
(CRON)
En production
POST /v1/clockwork/jobsClockwork
Cron‑as‑a‑Service
Planifiez des tâches récurrentes et différées via une simple API. Reprises automatiques et journal de chaque exécution.
(TELEGRAM)
En production
POST /v1/passepartout/login/startPassepartout
Telegram Auth-as-a-Service
Permettez aux utilisateurs finaux de votre tenant de s'inscrire et de se connecter via Telegram — sans mot de passe, sans flux e-mail, sans coût SMS. Intégration bot clé en main avec isolation totale par tenant.
(Rust + Go · Performances bare‑metal)
- Validation des clés API
- < 1ms
- Objectif de SLA plateforme
- > 99.9%
- Moteurs éprouvés
- Svix + Ory
Conçue avec Rust mémoire-sûr et des moteurs Go hautement concurrents, notre architecture élimine les surcoûts traditionnels : pas de Postgres sur le chemin critique, pas de démarrage à froid entre une requête et sa réponse. Plutôt que de promettre un chiffre de latence ici, nous publions le vrai — en direct sur notre page de statut.
(Comment ça marche)
Intégrez en trois étapes
Inscription
Créez votre compte Nautilus gratuitement. Aucune carte bancaire requise.
Obtenez votre clé API
Générez une clé avec portée depuis le tableau de bord (par ex. vrn_relay_...).
Commencez à construire
Appelez notre API depuis votre backend. Nous gérons le reste.
(Pourquoi Nautilus)
Pensé autrement
Authentification en microsecondes
Sur le chemin critique, votre clé API ne touche jamais Postgres : la passerelle vérifie son empreinte et décrémente votre quota en une seule lecture en mémoire. Authentification, limitation de débit et comptage partagent ce même passage, si bien que la validation reste sous la milliseconde, même en pic de trafic.
Isolation des locataires
La portée du locataire est transmise de la passerelle jusqu'à la base de données. Clés API, endpoints de webhooks, tâches planifiées et identités Telegram sont cloisonnés par locataire : les données d'un client ne peuvent jamais être lues – ni facturées – sous le compte d'un autre. C'est la plateforme qui l'impose, pas votre code.
Tarification à l'usage
Vous payez les requêtes que vous envoyez réellement : 3 000 par mois sont offertes, puis 3 € par tranche de 10 000. La mesure se fait par locataire et reste visible dans votre tableau de bord, et un plafond de dépense mensuel garantit que la facture ne s'emballe jamais.
Moteurs auto‑hébergeables
Le plan de données repose sur de l'open source que vous pouvez auditer et emporter : Svix pour les webhooks, Ory Kratos pour l'identité. La planification est la nôtre, et chaque job et chaque exécution restent lisibles via l'API. Nous gérons les clusters, les mises à jour et l'astreinte – mais si vos besoins changent, ces mêmes moteurs tournent sur votre propre infrastructure.
Pourquoi Verne, alors qu'AWS, Google Cloud et Azure ont aussi des centres de données à Francfort et en Irlande ?
AWS vous donne un centre de données brut, pas une solution métier prête à l'emploi. Pour faire tourner la livraison de webhooks, l'authentification et le cron sur AWS, il faut recruter un ingénieur DevOps, configurer SQS, Lambda, Cognito et EventBridge, les relier entre eux et écrire vous-même la supervision — des semaines d'ingénierie avant la première requête client, et cela reste à votre charge ensuite. Verne vous donne une API prête pour la production à partir de 19 € en dix minutes — pas un kit à assembler puis à maintenir pendant des mois.
Le RGPD, ce n'est pas juste un serveur dans l'UE : ce sont des accords juridiques (DPA) et des processus de traitement et de suppression des données.
Verne est conçu dès l'origine selon le principe du Privacy by Design. Nous ne conservons pas de données superflues (minimisation des données), nous proposons des DPA (accords de traitement des données) transparents et nous fournissons des endpoints d'API prêts à l'emploi pour la suppression complète des données d'un utilisateur à la première demande (droit à l'oubli).
Si Verne tombe, mes webhooks, mon authentification et mon cron tombent tous en même temps. C'est un point de défaillance unique.
À l'intérieur de Verne, les moteurs sont isolés les uns des autres. Relay, Gate et Clockwork tournent comme des services distincts sur des stockages distincts : une panne de l'un n'arrête pas les autres, et un worker cron bloqué laisse intactes l'authentification et la livraison des webhooks. La seule surface commune est la fine passerelle edge qui vérifie les clés d'API et compte l'usage — elle ne conserve aucune donnée des moteurs.
Il est plus simple pour moi de prendre l'offre gratuite de Supabase ou Firebase que de payer 19 € pour Verne.
Verne a aussi une offre gratuite : 3 000 requêtes par mois, tous les moteurs inclus. La différence apparaît plus tard : Supabase et Firebase attendent que vos données vivent chez eux, donc dès que les webhooks ou l'authentification doivent fonctionner avec une base que vous exploitez déjà — PostgreSQL, MySQL, MongoDB — vous reconstruisez votre backend autour du leur. Verne se pose par-dessus le code que vous avez déjà : votre base reste où elle est et vous appelez une API HTTP depuis n'importe quelle stack.
C'est trop bon marché. Soit le service est fragile, soit vous augmenterez les prix une fois la base d'utilisateurs constituée (dumping / bait-and-switch).
Le prix découle de la stack, pas d'une conquête de parts de marché. Tout ce qui achemine votre trafic est compilé — Rust pour la passerelle et l'API, Rust et Go pour les moteurs eux-mêmes (Svix, Ory Kratos et notre propre planificateur en Rust) — et des services compilés encaissent bien plus de trafic par gigaoctet de RAM que leurs équivalents Node.js et Python. Notre facture d'infrastructure par requête reste donc faible, et la grille tarifaire est l'endroit où nous vous la répercutons. Et si l'affaire cesse d'être bonne : Svix et Kratos sont open source, vous pouvez les reprendre et les héberger vous-même.
(Commencer)
Quatre moteurs, une seule API, en production depuis la 1.0
Quatre moteurs tournent en production aujourd'hui, avec des SDK officiels pour Node, Python, PHP et Rust et une version publiée derrière chaque correctif. Créez un compte, générez une clé : les 3 000 premières requêtes de chaque mois sont offertes.