Appuyez sur / pour rechercher

Toute la documentation
docs Faites-le tourner quelque part Uplink

S’exécute surWrit CloudDesktopAuto-hébergé

uplink ▸ de l’intérieur

Dans votre réseau. Appelable de l’extérieur.

Un système interne sans API devient un endpoint HTTPS. L’agent appelle vers l’extérieur et reste connecté ; une requête vers votre endpoint descend cette connexion, et le workflow s’exécute sur votre machine, contre un système que lui seul voit.

La connexion est sortante uniquement — vous n’ouvrez aucun port entrant pour Writ, et le système interne ne reçoit aucune adresse publique.

connexion ▸ un seul sens

L’agent appelle vers l’extérieur. Rien n’entre.

Tout repose sur une propriété : la connexion part de l’intérieur de votre réseau, vers l’extérieur, et reste ouverte. Le travail descend une connexion que vous avez déjà ouverte.

  1. 01
    L’agent se connecte vers l’extérieur

    Vous installez l’agent sur une machine qui atteint déjà le système interne. Il ouvre une connexion sortante vers Writ et la maintient.

  2. 02
    L’appel y descend

    Une requête vers votre endpoint publié passe par cette connexion existante. Writ n’ouvre pas de connexion vers votre réseau.

  3. 03
    Le workflow s’exécute à l’intérieur

    Le navigateur pilote le système interne depuis cette machine : l’exécution voit exactement ce que verrait quelqu’un assis à ce poste.

Aucun port entrant à ouvrir, aucune adresse publique à donner au système interne. Ce dont l’agent a besoin, c’est le HTTPS sortant que votre réseau autorise déjà.

pièces ▸ quatre

Ce qu’il faut.

Quatre éléments, chacun documenté sur sa propre page. Cette page donne l’ordre dans lequel les assembler.

Une machine dans le réseauWrit Desktop ou un agent auto-hébergé, sur un hôte qui atteint déjà le système que vous voulez appeler.
Un workflowEnregistré une fois contre ce système — ou décrit en mots — puis pointé vers votre propre agent pour qu’il s’y exécute.
Un endpoint publiéLa porte d’entrée sur Writ Cloud : une méthode et un chemin que vous choisissez, servis sous /v1/{slug}/{path}.
Une clé consommateurCe que présentent vos appelants. Restreignez-la à un endpoint, donnez-lui une limite de débit, faites-la tourner avec une période de grâce.

mise en place ▸ dans l’ordre

Assemblez-le.

Chaque étape est du travail produit ordinaire — rien ici n’est propre aux systèmes internes, sauf l’endroit où se trouve l’agent.

  1. 01
    Installez et liez l’agent

    Sur une machine dans le réseau. Une fois lié, il apparaît dans votre liste d’agents et maintient sa connexion sortante.

  2. 02
    Apprenez le workflow

    Enregistrez la tâche contre le système interne, ou décrivez-la et laissez la session IA l’enregistrer. Les identifiants sont résolus depuis le coffre à l’exécution.

  3. 03
    Pointez-le vers votre agent

    Réglez le workflow pour qu’il s’exécute sur votre agent plutôt que dans le cloud, afin que chaque exécution ait lieu sur une machine qui voit le système.

  4. 04
    Publiez l’endpoint

    Choisissez la méthode et le chemin. Ce chemin devient l’API que le système interne n’a jamais eue.

  5. 05
    Distribuez une clé consommateur

    Une clé par appelant. Limitez-la aux endpoints nécessaires, révoquez-la ou faites-la tourner sans toucher au workflow.

appel ▸ de n’importe où

Appelez-le comme n’importe quelle API.

Les appelants ne savent pas — et n’ont pas besoin de savoir — où l’exécution a lieu. Ils postent sur votre chemin avec leur clé et lisent le résultat.

call.sh

curl -X POST https://api.usewrit.app/v1/acme/price-check \
  -H "Authorization: Bearer $WRIT_CONSUMER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/product/42"}'

Les appels sont synchrones par défaut. Demandez un 202 et un identifiant d’exécution avec Prefer: respond-async, et servez un résultat récent au lieu d’une nouvelle exécution avec Cache-Control: max-age=N. Les formes de réponse, les codes de statut et le chemin de polling sont sur la page des endpoints gérés.

partage ▸ qui fait quoi

Ce qui s’exécute où.

La séparation mérite d’être précise, car c’est elle qui rend l’exposition sûre.

CôtéCe qu’il détient
Votre machineLe navigateur, la connexion au service, les identifiants et chaque octet lu depuis le système interne. L’exécution a lieu ici.
Writ CloudLa porte d’entrée : authentification, limites de débit, quotas et journal d’exécution. Elle retient la requête de l’appelant pendant que votre agent travaille.

Les exécutions sur votre propre agent sont gratuites et non facturées. La porte d’entrée cloud applique toujours les limites de débit et le quota mensuel de votre plan.

limites ▸ ce qui plafonne

Les limites à connaître.

Voici les nombres qui décident du nombre de portes et de la force avec laquelle on peut y frapper.

Agents liésFree, Starter et Pro en incluent un. Growth en permet 5, Scale 20, Enterprise est sans plafond.
Endpoints publiésPlafonnés par plan. Publier un chemin en consomme un.
Limite de débitPar clé consommateur, 60 requêtes par minute sauf si vous fixez la vôtre, plus le quota mensuel d’appels de votre organisation.
Délai5 à 300 secondes par endpoint, 120 par défaut. Au-delà, un 504 est renvoyé avec un identifiant d’exécution à interroger.

questions ▸ posées

Uplink, en clair.

Dois-je ouvrir un port ?
Non. L’agent établit la connexion vers l’extérieur et le travail redescend par celle-ci. Aucun port entrant pour Writ, et le système interne n’a pas besoin d’adresse publique.
Le système interne doit-il avoir une API ?
Non — c’est tout l’intérêt. Le workflow pilote son interface comme le ferait une personne, et l’endpoint que vous publiez devient l’API qu’il n’a jamais eue.
Deux machines peuvent-elles servir un endpoint ?
Oui. Liez plusieurs agents et un appel est confié à l’un de ceux qui sont connectés. Le nombre d’agents liés est ce que votre plan plafonne.
Est-ce facturé ?
Les exécutions sur votre propre agent sont gratuites et non facturées. La porte d’entrée cloud compte toujours les appels dans les limites de débit et le quota mensuel de votre plan.

fin ▸ ouvrir une porte

Mettez un système interne derrière un endpoint.

Commencez par la mécanique des endpoints, puis décidez où l’exécution doit avoir lieu.