Essayer l'API avec curl

Créez un espace, gardez son uuid. Quiconque l'a peut lire et écrire ici.

Créez une tâche, gardez son uuid.

Rapportez la progression. Chaque écriture remplace l'état entier — envoyez tout à chaque fois.

Terminez-la. C'est ce qui envoie la notification.

C'est toute la surface, et c'est ce qu'appellent la CLI et les outils MCP. Pour quelque chose que vous lancez tous les jours, la CLI c'est une ligne au lieu de quatre ; pour construire dessus, la référence de l'API et OpenAPI 3.1 sont sur /openapi.json.

Encore une, pour un client incapable de ce qui précède. Certaines choses ne peuvent recevoir qu'une URL — un pinger d'uptime, un champ webhook dans le produit de quelqu'un d'autre, un routeur ou un capteur, une ligne de cron avec un curl nu. Ils ne peuvent ni choisir une méthode ni envoyer un corps, la même écriture est donc joignable par un simple GET.

Le -g est pour curl, pas pour nous : curl lit les crochets d'une URL comme une plage et refuse l'adresse sans lui. Tout ce qui se contente de déclencher une URL n'a besoin de rien de particulier.

Ne l'utilisez que faute d'alternative. C'est un GET qui écrit, donc tout ce qui suit l'URL effectue l'écriture : collez-la dans une conversation et l'aperçu du lien rapporte à votre place. Si votre client peut envoyer un corps de requête, le PUT ci-dessus est celui à utiliser.