Workflows serveur · Docs

Les workflows serveur sont votre backend : points de terminaison d’API, gestionnaires de webhooks, tâches planifiées et réactions aux changements de données. Ils utilisent le même éditeur visuel et le même modèle d’étapes que les workflows client, mais s’exécutent sur l’edge de Cloudflare, peuvent utiliser des secrets, écrire dans des tables et envoyer des e-mails.

Déclencheurs

HTTP endpointGET, POST, PUT, PATCH ou DELETE sur https://your-site/api/…, avec des :params dans le chemin.

WebhookUn point de terminaison POST qui vérifie les signatures Stripe, GitHub ou HMAC avant la première étape.

CronUne planification à cinq champs en UTC, comme 0 9 * * 1 pour le lundi à neuf heures.

Table eventUne ligne insérée, modifiée ou supprimée dans une table native.

Called from pagesLes workflows client l’exécutent avec Run server workflow, pour tout le monde ou seulement pour les visiteurs connectés.

ManualUniquement depuis des exécutions de test ou un autre workflow serveur. Les pages ne peuvent pas l’appeler.

En créer un

Dans l’espace de travail Logic, passez aux workflows serveur et créez-en un. Choisissez un déclencheur et ajoutez des étapes. À l’intérieur, input, user et steps sont disponibles. Return termine l’exécution ; pour les points de terminaison, sa valeur est le corps de la réponse.

json

{
  "name": "Create order",
  "runtime": "server",
  "trigger": { "type": "http", "method": "POST", "path": "/orders", "auth": "user" },
  "input": { "schema": { "items": "array", "couponCode": "string?" } },
  "steps": [
    { "id": "order", "action": "core.tableInsert",
      "params": { "table": "orders", "values": { "userId": { "$expr": "user.id" }, "items": { "$expr": "input.items" } } } },
    { "id": "mail", "action": "core.sendEmail",
      "params": { "to": { "$expr": "user.email" }, "subject": "Order received", "text": "Thanks!" } },
    { "id": "done", "action": "core.return", "params": { "value": { "$expr": "{ orderId: steps.order.id }" } } }
  ]
}

Une fois publié, le point de terminaison est en ligne sur tous les domaines de l’environnement :

bash

curl -X POST https://shop.example.com/api/orders \
  -H 'content-type: application/json' \
  -d '{ "items": [{ "sku": "mug", "qty": 2 }] }'

Authentification des points de terminaison

public : tout le monde peut l’appeler. Les points de terminaison publics sont soumis à une limitation de débit.
user : uniquement les visiteurs connectés ; user est l’appelant.
apiKey : réservé aux appels de serveur à serveur (pas encore disponible).

L’appeler depuis une page

Les étapes d’intégration (OpenAI, Stripe, Resend…) ont besoin de vos clés secrètes, elles ne s’exécutent donc que dans des workflows serveur. Pour en utiliser une depuis un bouton ou un formulaire :

Créez un workflow serveur avec le déclencheur Called from pages. Choisissez qui peut l’appeler : tout le monde, ou seulement les visiteurs connectés.
Ajoutez l’étape d’intégration. Lisez ce que la page envoie dans input, puis terminez par Return.
Dans le workflow client, ajoutez Run server workflow et choisissez-le. Son entrée devient input ; la valeur renvoyée arrive dans steps.<id>.

Run in preview exécute le brouillon avec votre compte. Les pages publiées exécutent la version publiée. Une étape de plugin restée dans un workflow client affiche Move to a server workflow, qui fait ces étapes pour vous.

Exécutions de test et historique

Cliquez sur Test run avec une entrée d’exemple. Les étapes s’affichent en direct dans le panneau d’exécution, avec chaque résultat et sa durée. Les exécutions de test utilisent le brouillon ; les exécutions publiées utilisent la version qui a été publiée : les exécutions en cours ne voient donc jamais vos modifications. Chaque exécution est conservée dans l’historique avec son statut : en cours, en attente, réussie ou échouée.

Workflows de longue durée

Ajoutez Sleep (de quelques minutes à plusieurs jours) ou Wait for event et le workflow devient automatiquement durable. Les exécutions durables survivent aux redémarrages, font de nouvelles tentatives sur les étapes échouées avec un délai croissant et peuvent attendre un lien d’approbation ou une confirmation de paiement. Reprenez une exécution en attente avec Emit event depuis un autre workflow. Un point de terminaison qui lance une exécution durable répond immédiatement avec son runId.

Étapes réservées au serveur

HTTP request : appelez n’importe quelle API HTTPS ; les adresses privées sont bloquées, délai de 15 s, plafond de 1 Mo.
Send email : un e-mail transactionnel en texte ou en HTML.
Query, get, insert, update, delete row : travaillez avec les tables natives.
Set visitor roles : accordez ou retirez des rôles à un visiteur inscrit.
Run JavaScript : du code isolé (sandbox) avec input et steps disponibles, sans réseau ni secrets.
Run operation : appelez une opération d’intégration avec ses secrets. Pour l’utiliser depuis une page, voir L’appeler depuis une page.
Run server workflow, Return, Sleep, Wait for event, Emit event.

Chaque étape peut définir des retries (jusqu’à 5) avec un délai constant, linéaire ou exponentiel.

Limites

Le forfait de votre site fixe le nombre d’exécutions par mois et d’étapes par exécution ; voir Forfaits. Les exécutions directes abandonnent au bout de 30 secondes. Les événements de table qui déclenchent des workflows écrivant dans des tables s’arrêtent après trois niveaux : un workflow ne peut pas boucler sur lui-même.