Pour développeurs & intégrateurs

Créez un workflow. Testez-le sans risque. Déployez-le selon les besoins du client.

Connectez les systèmes existants du client, décrivez le travail en YAML et exploitez le résultat depuis votre propre assistant. titop.ai accompagne les intégrateurs dans des projets techniques guidés, avec validation humaine avant tout envoi.

01 · Ce que vous pouvez connecter

Partez des systèmes que votre client utilise déjà.

Conservez la boîte mail, le CRM, le calendrier et les documents dans leur environnement actuel. Utilisez les connecteurs disponibles ou étudiez une intégration personnalisée avec l’adapters SDK.

Voir les intégrations prises en charge

Email

Disponible

Gmail / Google Workspace, Outlook / Microsoft 365 ou toute boîte mail via IMAP / SMTP ou redirection.

CRM

Disponible

Odoo, HubSpot et Salesforce, sans remplacer les outils quotidiens du client.

Calendriers

Disponible

Outlook Calendar et Google Calendar dans le périmètre d’accès défini pour l’environnement.

Document stores

Beta privée

Connectez les espaces documentaires dans une intégration cadrée ; nous confirmons avec vous le référentiel et les accès requis.

Billing

Design partners

Un adapter Stripe de référence en lecture seule montre comment l’état des factures peut alimenter un workflow sans modifier les données de facturation.

Vos propres identifiants

Beta privée

Utilisez vos propres identifiants fournisseur dans le périmètre d’accès défini pour votre tenant.

Connectez votre propre système

L’adapters SDK et les packages de référence sont disponibles pour les design partners sur demande, avec un périmètre confirmé pendant l’évaluation technique.

  • Utilisez un contrat indépendant du fournisseur pour les intégrations CRM, LLM, calendrier ou billing.
  • Rendez l’intégration détectable par la plateforme grâce au plugin model du SDK.
  • Vérifiez la compatibilité avec les contract tests fournis avant activation.

02 · Comment décrire un workflow

Un document YAML lisible, basé sur un standard ouvert.

Décrivez un workflow en YAML basé sur CNCF Serverless Workflow 1.0. Utilisez des concepts familiers : triggers, actions, conditions, approvals, waits et boucles.

01

Validez le document avec le schema package avant de l’examiner pour l’environnement client.

02

Lisez chaque workflow de la bibliothèque comme un diagramme BPMN et comme du YAML, pour une revue commune entre techniques et métiers.

03

Définissez séparément les choix d’exécution, de fournisseur et d’accès pour chaque environnement client.

Le template schema package est disponible pour les design partners sur demande.

03 · Comment tester avant tout envoi

Répétez tout l’échange dans un environnement contrôlé.

Exécutez un workflow de bout en bout avec des acteurs scriptés plutôt que de tester sur un client. Examinez le résultat, comparez-le à l’attendu et réinitialisez avant un nouveau run.

Beta privée

Les scenario runs sont exercés avec nos intégrateurs dans un environnement contrôlé. Un captured run n’a pas besoin de laisser quoi que ce soit sortir de cet environnement.

  • 01 Exercez tout l’échange avec des captured scenario runs.
  • 02 Consultez la health de chaque run et une comparaison expected-versus-actual expurgée.
  • 03 Réinitialisez les données de test capturées à la fin du run.
  • 04 Utilisez le test mode pour les connecteurs et les contract tests pour les intégrations personnalisées.
  • 05 Vérifiez la compatibilité du template avant activation.

04 · Comment exploiter depuis votre assistant

Utilisez MCP avec les workflows et runs autorisés.

Beta privée

Connectez votre propre assistant à l’endpoint MCP fourni pour votre tenant. Travaillez avec quatre familles d’outils ciblées, selon le rôle et les autorisations du membre.

Templates

Examinez les workflows disponibles et demandez la publication d’une modification.

Traces

Inspectez l’historique des runs et leur health sous forme expurgée, sans contenu de message.

Scenarios

Démarrez et faites progresser un captured test run, puis examinez son statut.

Solutions

Parcourez les solution cards avec leurs résultats, leur maturité et leurs prérequis.

  • L’authentification utilise le rôle du membre et ses autorisations sur les templates.
  • La publication requiert l’accord du propriétaire ; la version actuelle continue de fonctionner jusque-là.
  • Les opérations sont auditées et les traces sont expurgées.

05 · Où l’exécuter

Choisissez la frontière de déploiement avec votre client.

Utilisez notre service suisse ou planifiez un déploiement dans l’environnement du client. Les données restent dans la frontière convenue et une personne valide les actions sortantes.

Disponible

SaaS suisse

Exécutez dans l’environnement SaaS suisse de titop, avec le périmètre de déploiement et d’accès défini pour votre tenant.

Beta privée

On-prem bundle

Déployez le release bundle sur votre matériel dans une mission cadrée, avec vérification de la release et installation convenues avec notre équipe.

En conception

Votre propre cloud

Exécutez la stack dans votre propre abonnement cloud lorsque le déploiement doit rester dans votre frontière cloud.

La validation humaine fait partie du modèle d’exploitation dans chaque déploiement : les actions sortantes et la publication attendent l’approbateur désigné.

06 · Obtenir l’accès

Apportez un workflow client à la beta privée.

Nous intégrons les intégrateurs et design partners dans une mission technique guidée. Commencez avec un workflow concret, un environnement et des critères d’acceptation clairs.

Réserver une démo développeur Contacter l’équipe développeurs
  • Un sandbox tenant pour l’évaluation
  • Les packages développeur et de référence sur demande
  • Un endpoint MCP et un périmètre d’autorisations défini
  • Un contact technique nommé pour les questions d’intégration et de déploiement