Une API REST. Le contenu publié (blog, recherche, offres, profils publics) est ouvert : ni inscription, ni clé, ni en-tête. La planification par IA demande un compte et un jeton porteur, borné par des portées OAuth déclarées. Le contrat complet est publié en OpenAPI 3.1 sur https://timyo.app/openapi.json.
Huit points d'entrée sous /api/public/ répondent en GET et HEAD, sans jeton, servis par le CDN : blog-list, blog-post, research-list, research-post, search, job-offers, public-profile, config.
Le débit est de 120 requêtes par minute et par adresse IP, ramené à 30 pour search.
POST /api/public/sandbox?op=parse ou op=plan renvoie une réponse de démonstration figée du planificateur, sans jeton et sans consommer de quota IA. Ces corps sont des fixtures : ils ne varient pas avec l'entrée, et portent « sandbox »: true ainsi que l'en-tête X-Timyo-Sandbox.
Les opérations de compte attendent un jeton émis par le serveur d'autorisation Supabase de Timyo, envoyé en Authorization: Bearer.
Six portées existent : content.read, tasks.parse, tasks.plan, usage.read, team.manage, account.security. Un jeton qui déclare une revendication scope est borné par elle ; toute opération dont il ne nomme pas la portée répond 403 insufficient_scope avec un en-tête WWW-Authenticate qui nomme la portée manquante.
Le catalogue est publié en métadonnée de ressource protégée (RFC 9728) sur https://timyo.app/.well-known/oauth-protected-resource.
Il n'existe pas encore de clés d'API : l'authentification passe par les jetons de session Supabase, à durée de vie courte. Les portées sont déjà déclarées et appliquées, mais l'émetteur de jetons restreints reste à construire.
Pour une intégration qui en a besoin, écrire à support@timyo.app.
Pour un agent : /llms.txt · /agents.md · /sitemap.xml