Tâches programmées

Une tâche est un prompt réutilisable que vous configurez une fois, puis qui s’exécute à la demande, selon un planning, ou sur appel d’API. À chaque exécution, la tâche mobilise les ressources que vous lui avez données (bases de connaissance, connecteurs, recherche web, exécution de code) et livre son résultat par email, message Slack ou webhook, en texte ou en JSON.

Une tâche reste une requête différée : un déclenchement = un appel au modèle + une livraison. Il n’y a pas de chaînage entre tâches ni de processus permanent.

Où créer une tâche

Les tâches se créent et se configurent dans le portail (/portal/taches) : prompt, variables, ressources, modèle, fréquence, sorties et format. La création demande une session (elle identifie le créateur, dont le périmètre est réutilisé à chaque exécution), elle n’est donc pas exposée par l’API.

L’API (/v1/tasks) sert ensuite à lister, lire, modifier, supprimer, déclencher une tâche et à consulter son historique, typiquement depuis une automatisation (Make, n8n, un cron, un script).

Les tâches sont propres à une organisation. L’API exige donc une clé d’organisation portant le scope tasks ; une clé personnelle est refusée.

Variables

Le prompt d’une tâche peut contenir des variables ${nom}. À chaque déclenchement, vous fournissez leurs valeurs dans un objet inputs. Les variables système ${date}, ${now} et ${task_name} sont toujours disponibles.

{ "inputs": { "dossier_id": "D-123", "priorite": "haute" } }

Endpoints

Toutes les routes exigent l’en-tête Authorization: Bearer sk-… (clé d’organisation, scope tasks).

Route	Verbe	Rôle
/v1/tasks	GET	Liste les tâches de l’organisation.
/v1/tasks/{slug}	GET	Détail d’une tâche.
/v1/tasks/{slug}	PATCH	Met à jour partiellement une tâche.
/v1/tasks/{slug}	DELETE	Supprime une tâche (et son historique).
/v1/tasks/{slug}/run	POST	Déclenche un run (trigger = api).
/v1/tasks/{slug}/runs	GET	Historique des runs (statuts, dates, livraisons).

Déclencher un run

POST /v1/tasks/{slug}/run accepte { "inputs": {…}, "wait": false }.

Par défaut (wait absent ou false), l’appel est asynchrone : il répond 202 avec un run_id, et le résultat est livré par les sorties configurées.

curl -X POST https://api.astrolabe.chat/v1/tasks/brief-quotidien/run \
  -H "Authorization: Bearer sk-…" \
  -H "Content-Type: application/json" \
  -d '{"inputs":{"dossier_id":"D-123"}}'

{ "run_id": "…", "status": "pending" }

Avec "wait": true, l’appel attend le résultat (borné par un délai côté serveur). Au-delà de ce délai, il répond 202 avec le run_id, à interroger via /runs.

{
  "run_id": "…",
  "status": "done",
  "output": "…",
  "error": null,
  "delivered": [{ "type": "email", "ok": true, "detail": "vous@org.fr" }]
}

En format JSON (réglage de la tâche), output est l’objet déjà parsé, directement exploitable dans l’étape suivante d’un scénario no-code.

Consulter l’historique

GET /v1/tasks/{slug}/runs renvoie les métadonnées d’exécution (statut, dates, état des livraisons). Le contenu du résultat n’est pas exposé par cette route ; utilisez wait:true sur /run pour récupérer le résultat d’une exécution.

Mémoire d’exécution

Une tâche peut, en option, relire ses propres exécutions passées (réglage dans le portail) : soit son dernier résultat, soit tout son historique (recherche). C’est utile pour des tâches incrémentales, par exemple « ne me signale que les nouveautés depuis le dernier passage ». C’est une lecture seule de ses propres sorties.

Depuis Make, Zapier ou n8n

Deux actions no-code, identiques d’une plateforme à l’autre :

• Lister les tâches (GET /v1/tasks) : pour construire un menu dynamique de tâches.
• Déclencher une tâche (POST /v1/tasks/{slug}/run) : sélection de la tâche dans une liste, inputs (objet JSON) et une option Attendre le résultat. Combinée à une sortie webhook de la tâche, cela ferme la boucle : votre scénario déclenche la tâche, la tâche répond sur le webhook du scénario.

Voir n8n / Make / code pour la configuration des connexions.