API REST de base de données

Votre base de données, une API REST en direct. En environ 90 secondes.

Transformez n'importe quelle requête enregistrée en un point de terminaison REST sécurisé et limité en débit : appelez-le vous-même depuis un tableau de bord, un script ou une application interne, ou partagez-en l'accès avec un partenaire. Chaque clé est associée à une seule requête, en lecture seule par défaut, et vos identifiants de base de données restent toujours sur votre réseau : aucune passerelle vers l'hôte, aucun middleware à exécuter.

~90 secondes jusqu'au point final Une seule clé par application ou partenaire · révoquez-la à tout moment Lecture seule · aucun port entrant Aucune passerelle vers l'hôte

Une seule requête. Lignes en direct. Aucun identifiant échangé.

Vous (ou un partenaire) appelez une URL stable à l'aide d'une clé personnelle. Query Streams exécute votre requête enregistrée via l'agent réseau, impose le mode lecture seule, mesure la consommation de ressources et renvoie un flux JSON, tandis que votre base de données reste isolée au sein de votre réseau.

Demandeboucle
boucle https://api.querystreams.com/v1/endpoints/8f3c1a… -H "Clé X-API : qsapi_8Fa3kZ…" \ -G --data-urlencode "région=EMEA"
200 OK142 lignes · 18 ms · 6,4 Ko sur le réseau (LZ4)
{
  "point de terminaison": "emea-active-accounts",
  "rangées": [
    { "compte": "Northwind GmbH", "mrr": 8400, "statut": "actif" },
    { "compte": "Contoso SARL",  "mrr": 6100, "statut": "actif" },
    … 140 lignes supplémentaires
  ],
  "méta": { "source": "PostgreSQL", "en cache": faux }
}

Le partenaire n'a jamais vu le code SQL, n'a jamais obtenu d'identifiants de base de données et ne peut exécuter que cette seule requête — et vous voyez chaque appel dans votre registre d'activité.

Une requête à titre d'exemple avec des données de test.

La grande idée

Vous partagez les capacités, mais pas les clés du royaume.

La plupart des outils d'API de base de données exposent l'intégralité de votre schéma et permettent aux utilisateurs de parcourir vos tables. Query Streams fonctionne à l'inverse : une seule requête est utilisée. requête enregistrée définit précisément ce qu'un point de terminaison renvoie — et votre partenaire reçoit ces lignes et rien d'autre sur la façon dont elles ont été produites.

Ce que votre partenaire reçoit

  • Une URL de point de terminaison stable + leur propre clé API
  • Lignes JSON/CSV en direct, en lecture seule
  • Paramètres de filtrage qui remodèlent la requête — sans l'exposer

Ce qu'ils n'obtiennent jamais

  • Vos noms SQL, de schéma ou de table
  • Une chaîne d'identification de base de données ou de connexion
  • Tout accès en écriture — ou un chemin d'accès à votre réseau

Pourquoi les équipes le choisissent plutôt que PostgREST et les passerelles DIY

Vous pouvez mettre en place une API PostgREST ou Express + Knex en un après-midi. Voici ce que cette approche artisanale ne permet pas d'égaler lorsque vous partagez des données avec quelqu'un. dehors votre entreprise.

Rien n'est exposé à Internet

L'agent réseau ouvre une connexion sortante et achemine les requêtes depuis votre réseau interne. Aucun port de pare-feu, aucune réplique en lecture, aucun VPN, aucun serveur API public à sécuriser : une approche approuvée par les équipes de sécurité.

Une clé par partenaire, pas un secret partagé

Chaque bénéficiaire reçoit le sien qsapi_* Chaque utilisateur dispose de sa propre clé, de sa propre limite de débit et d'une ligne distincte dans son registre d'utilisation. Révoquez-en une en un clic sans toucher aux autres : aucun service de gestion des clés à mettre en place.

En lecture seule — et le SQL reste à vous

Chaque appel passe par un validateur en lecture seule codé en dur (SELECTIONNER / AVEC / EXPLIQUERLe destinataire exécute le point de terminaison, mais ne voit jamais la requête sous-jacente et ne peut pas la modifier. Vous partagez la capacité, pas le modèle.

Tout ce que vous pourriez ajouter à une API maison — intégré

Un point de terminaison n'est pas qu'une simple URL. Chacun inclut la couche d'expérience développeur que vous devriez normalement assembler à partir d'une passerelle, d'un générateur de documentation, d'un service d'authentification et d'un pipeline de mesure.

API OpenAPI 3.1 générée automatiquement

Chaque point de terminaison émet une spécification réelle à /openapi.json À partir de l'analyse du schéma de l'agent, intégrez-le à Swagger UI, à un générateur de client ou à un LLM. Aucune documentation manuscrite.

Bac à sable de test intégré au navigateur

Un panneau « essayez-le maintenant » est situé à côté de chaque point de terminaison : lancez un appel, appliquez des filtres et visualisez les lignes en direct, l’état, la latence et la taille compressée/décompressée sans quitter le portail.

JSON, NDJSON, CSV et flux continu

Renvoie des résultats au format JSON, NDJSON délimité par des sauts de ligne ou CSV pour chaque requête, et traite les grands ensembles de résultats en continu afin qu'une tâche n'attende pas la totalité des données. L'option LZ4 permet de réduire la taille des réponses analytiques de 3 à 5 fois.

Permanent, à durée de vie limitée et à autodestruction

Attribuez une durée de vie à chaque point de terminaison : conservez-le. permanent, ayez-le expirer à une date, ou fixez une budget d'appel qui s'autodétruit après le dernier appel autorisé — idéal pour un dépôt de données unique et sécurisé.

Limites de débit, quotas, verrouillages IP et CORS

Cumulez des limites de débit à deux niveaux (par clé et par point de terminaison), un quota mensuel d'octets, une liste blanche d'adresses IP par clé et une liste d'origines CORS par point de terminaison — réduisez le rayon d'action avant même de partager une clé.

S'intègre à Power BI et Tableau

Une API REST propre, conforme à la spécification OpenAPI 3.1 et prenant en charge les sorties JSON/CSV, s'intègre directement dans Power BI et Tableau via leurs connecteurs web/REST — idéaux pour vos propres tableaux de bord et rapports internes — ainsi que des paramètres de filtrage (région, depuis, locataire) pour que vous ou vos destinataires puissiez façonner les données.

De la requête enregistrée au point de terminaison partagé, en quatre étapes

L'ancienne méthode nécessitait des identifiants, une réplique ou une exportation nocturne. Cette nouvelle méthode utilise un point de terminaison en lecture seule et actif en direct.

01

Sélectionnez une requête enregistrée

Rédigez-la une seule fois dans Query Builder pour n'importe quelle base de données connectée, avec des paramètres de filtre optionnels que votre partenaire peut transmettre.

02

Retournez-le à un point final

Nommez-le, définissez des limites de débit et une durée de vie (permanente, temporaire ou à autodestruction), et vous obtenez une solution stable. api.querystreams.com URL.

03

Partagez-le — de deux façons

Envoyez-leur une invitation par lien magique par e-mail et ils récupèrent une clé traçable et révocable en quelques secondes, ou générez une clé de service à remettre directement à un script.

04

données en direct d'appel

Votre tableau de bord, une application interne, un flux n8n, une feuille de calcul ou l'application d'un partenaire accède au terminal à la demande. Vous visualisez chaque appel et pouvez révoquer l'accès à tout moment.

Flux de requêtes vs PostgREST, Hasura et passerelles DIY

Les grandes plateformes en font bien plus que nous — nous ne les surpassons pas en termes de visibilité. Nous nous contentons d'un seul travail, partager une requête en toute sécurité avec un partenaire, nettement plus simple et moins cher.

PostgREST / Hasura / Passerelle DIY

  • Votre base de données ou votre serveur API public doit être accessible depuis Internet.
  • Vous hébergez, mettez à l'échelle, corrigez et renouvelez le protocole TLS sur l'ensemble de la pile.
  • Vous mettez en place la gestion des clés, la rotation et la mesure par clé
  • Votre schéma est l'API — les partenaires consultent vos tables
  • Souvent, un seul moteur de base de données (PostgREST = Postgres uniquement)

Plateforme API Query Streams

  • Aucune exposition — agent sortant uniquement, aucun port, aucun VPN
  • Nous hébergeons l'API, les clés, les quotas, le TLS et la mise à l'échelle ; vous gérez un agent.
  • Une clé par partenaire, enregistrée, révocation en un clic
  • C’est une requête — et non votre schéma — qui définit ce que le point de terminaison expose.
  • 11 moteurs de bases de données, sur site ou dans le cloud, à partir d'un seul agent

Les passerelles API complètes (Kong, Apigee, CData) sont performantes et ont toute leur utilité ; Query Streams ne les remplace pas. C'est une solution plus simple et plus économique pour une tâche précise : partager des données en temps réel avec des partenaires, fournisseurs et clients désignés, sans avoir à déployer ni à financer l'ensemble de ces solutions.

Toutes les bases de données SQL populaires, exposées sous forme d'API REST

38 Des connecteurs de base de données sur le même agent réseau qui gère déjà Excel, Sheets et MCP — aucune configuration supplémentaire. requête fédérée La publication se fait de la même manière : votre consommateur appelle un point de terminaison et reçoit des lignes déjà jointes à travers plusieurs bases de données, sans savoir qu’il y en a jamais eu plus d’une.

Microsoft SQL ServerPostgreSQLMySQLMariaDBOracleFlocon de neigeGoogle BigQuerySQLiteMicrosoft AccessDuckDBSupabase

FAQ sur la plateforme API

Mes partenaires ont-ils besoin d'un compte ou d'identifiants de base de données ?

Ni l'un ni l'autre. Invitez une personne par e-mail et elle utilisera un lien magique : une organisation gratuite est créée en quelques secondes et elle obtient sa propre clé de suivi (idéal pour l'attribution et la révocation en un clic). Ou bien, générez une clé de service et transmettez-la directement à son script : aucun compte n'est requis. Dans les deux cas, elle n'obtient jamais d'identifiants de base de données, de chaîne de connexion ni de code SQL ; elle se contente d'appeler une URL stable. Clé X-API et obtenir les lignes en direct.

Comment les partenaires peuvent-ils modifier les données sans voir la requête ?

Par le biais des paramètres de filtre. Vous exposez les variables dans votre requête enregistrée. région, depuis, locataire — sous forme de paramètres de requête. Le destinataire transmet des valeurs pour modifier le résultat de la requête, mais n'accède jamais au code SQL lui-même. La requête contrôle précisément ce que le point de terminaison peut exposer ; les filtres servent uniquement à le contraindre à respecter ces limites.

Dois-je héberger ou maintenir quoi que ce soit ?

Non. Nous hébergeons l'API, les clés, les quotas, le TLS et la mise à l'échelle. Il vous suffit d'exécuter l'agent réseau léger, dédié aux requêtes sortantes, sur votre réseau ; aucun serveur API, middleware de limitation de débit, réplique en lecture seule ou serveur Express n'est à déployer ou à mettre à jour.

Que se passe-t-il si le destinataire tente d'écrire ou de supprimer ?

Ils ne peuvent pas. Chaque appel passe par un validateur en lecture seule codé en dur chez l'agent — seulement SELECTIONNER, AVEC et EXPLIQUER Les requêtes sont acceptées, et le destinataire ne peut exécuter que la requête enregistrée associée au point de terminaison. Il est impossible d'écrire, de supprimer, de modifier ou d'accéder à une autre table.

Quels forfaits incluent l'API REST, et que paient les bénéficiaires ?

L'API REST de la base de données est incluse dans les forfaits Business et Enterprise, avec un essai gratuit de 30 jours à l'inscription et sans carte de crédit requise. Vos destinataires ne paient rien pour utiliser un point de terminaison : la facturation se fait au volume de données compressé (taille du transfert indiquée dans votre relevé), sans frais par utilisateur.

Partagez des données en direct en 90 secondes — pas vos identifiants.

Transformez une requête enregistrée en un point de terminaison REST sécurisé et dédié à chaque destinataire. En lecture seule, révocable, et aucune donnée ne quitte votre réseau.