Für Entwickler & Integratoren

Workflow erstellen. Sicher testen. Dort betreiben, wo Ihr Kunde es braucht.

Verbinden Sie die vorhandenen Systeme Ihres Kunden, beschreiben Sie die Arbeit in YAML und betreiben Sie das Ergebnis über Ihren eigenen Assistant. titop.ai arbeitet mit Integratoren in geführten technischen Projekten mit menschlicher Freigabe vor jedem Versand.

01 · Was Sie anbinden können

Beginnen Sie mit den Systemen Ihres Kunden.

Postfach, CRM, Kalender und Dokumente bleiben in ihrer bestehenden Umgebung. Nutzen Sie die verfügbaren Connectoren oder besprechen Sie eine individuelle Integration über das adapters SDK.

Unterstützte Integrationen ansehen

E-Mail

Verfügbar

Gmail / Google Workspace, Outlook / Microsoft 365 oder jedes Postfach über IMAP / SMTP oder Weiterleitung.

CRM

Verfügbar

Odoo, HubSpot und Salesforce, ohne die täglichen Arbeitswerkzeuge des Kunden zu ersetzen.

Kalender

Verfügbar

Outlook Calendar und Google Calendar innerhalb des für die Umgebung vereinbarten Zugriffsumfangs.

Document Stores

Private Beta

Binden Sie Dokumentenablagen in einer abgegrenzten Integration an; Repository und Zugriffsanforderungen klären wir mit Ihnen.

Billing

Design Partner

Ein Read-only-Referenzadapter für Stripe zeigt, wie Rechnungsstatus einen Workflow unterstützen können, ohne Billing-Daten zu verändern.

Eigene Zugangsdaten

Private Beta

Nutzen Sie eigene Provider-Zugangsdaten innerhalb des für Ihren Tenant vereinbarten Zugriffsumfangs.

Ihr eigenes System verbinden

Das adapters SDK und die Referenzpakete sind für Design Partner auf Anfrage verfügbar; der Integrationsumfang wird in der technischen Evaluierung festgelegt.

  • Nutzen Sie einen provider-neutralen Contract für CRM-, LLM-, Kalender- oder Billing-Integrationen.
  • Machen Sie die Integration über das Plugin-Modell des SDK für die Plattform auffindbar.
  • Prüfen Sie die Kompatibilität vor der Aktivierung mit den mitgelieferten Contract Tests.

02 · Wie Sie einen Workflow beschreiben

Ein lesbares YAML-Dokument auf einem offenen Standard.

Beschreiben Sie einen Workflow in YAML auf Basis von CNCF Serverless Workflow 1.0. Arbeiten Sie mit vertrauten Konzepten wie Triggern, Actions, Conditions, Approvals, Waits und Loops.

01

Validieren Sie das Dokument mit dem Schema Package, bevor Sie es für die Kundenumgebung prüfen.

02

Lesen Sie jeden Bibliotheks-Workflow als BPMN-Diagramm und als YAML, damit Technik und Fachbereich denselben Ablauf prüfen können.

03

Vereinbaren Sie Laufzeit-, Provider- und Zugriffsoptionen separat für jede Kundenumgebung.

Das Template Schema Package ist für Design Partner auf Anfrage verfügbar.

03 · Wie Sie vor jedem Versand testen

Den gesamten Austausch in einer kontrollierten Umgebung durchspielen.

Führen Sie einen Workflow mit scripted actors End to End aus, statt bei einem Kunden zu experimentieren. Prüfen Sie das Ergebnis, vergleichen Sie es mit der Erwartung und setzen Sie vor dem nächsten Run zurück.

Private Beta

Scenario Runs werden mit unseren Integratoren in einer kontrollierten Umgebung ausgeführt. Bei einem Captured Run muss nichts diese Umgebung verlassen.

  • 01 Prüfen Sie den gesamten Austausch mit Captured Scenario Runs.
  • 02 Lesen Sie Health pro Run und einen redigierten Expected-versus-Actual-Vergleich.
  • 03 Setzen Sie die erfassten Testdaten nach dem Run zurück.
  • 04 Nutzen Sie Test Mode für Connectoren und Contract Tests für individuelle Integrationen.
  • 05 Prüfen Sie die Template-Kompatibilität vor der Aktivierung.

04 · Betrieb über Ihren eigenen Assistant

Nutzen Sie MCP für freigegebene Workflows und Runs.

Private Beta

Verbinden Sie Ihren eigenen Assistant mit dem MCP Endpoint Ihres Tenants. Arbeiten Sie mit vier klar abgegrenzten Tool-Familien entsprechend Rolle und Grants des Mitglieds.

Templates

Prüfen Sie verfügbare Workflows und fordern Sie die Veröffentlichung einer Änderung an.

Traces

Prüfen Sie redigierte Run-Historie und Execution Health ohne Nachrichteninhalte.

Scenarios

Starten und steuern Sie einen Captured Test Run und prüfen Sie anschließend seinen Status.

Solutions

Durchsehen Sie Solution Cards mit Ergebnissen, Reifestatus und Anforderungen.

  • Die Authentifizierung verwendet die eigene Rolle des Mitglieds und dessen Template-Grants.
  • Die Veröffentlichung erfordert die Owner-Freigabe; bis dahin läuft die aktuelle Version weiter.
  • Operationen werden auditiert und Traces redigiert zurückgegeben.

05 · Wo der Betrieb stattfindet

Wählen Sie die Deployment-Grenze mit Ihrem Kunden.

Nutzen Sie unseren Schweizer Service oder planen Sie ein Deployment in der Umgebung des Kunden. Daten bleiben innerhalb der vereinbarten Grenze und ausgehende Aktionen werden von einem Menschen freigegeben.

Verfügbar

Swiss SaaS

Betrieb in der Schweizer SaaS-Umgebung von titop mit dem für Ihren Tenant vereinbarten Deployment- und Zugriffsumfang.

Private Beta

On-Prem Bundle

Stellen Sie das Release Bundle in einem abgegrenzten Projekt auf Ihrer Hardware bereit; Release-Verifizierung und Setup werden mit unserem Team vereinbart.

In Konzeption

Ihre eigene Cloud

Betreiben Sie den Stack in Ihrem eigenen Cloud-Abo, wenn das Deployment innerhalb Ihrer eigenen Cloud-Grenze bleiben muss.

Menschliche Freigabe gehört in jedem Deployment zum Betriebsmodell: Ausgehende Aktionen und Veröffentlichungen warten auf die benannte freigebende Person.

06 · Zugang erhalten

Bringen Sie einen Kundenworkflow in die Private Beta.

Wir binden Integratoren und Design Partner in einem geführten technischen Projekt ein. Beginnen Sie mit einem konkreten Workflow, einer Umgebung und klaren Abnahmekriterien.

Developer-Demo buchen Developer-Team kontaktieren
  • Ein Sandbox Tenant für die Evaluierung
  • Developer- und Referenzpakete auf Anfrage
  • Ein MCP Endpoint mit einem abgegrenzten Satz von Grants
  • Ein benannter technischer Ansprechpartner für Integrations- und Deployment-Fragen