Automatyzacje

Automatyzacje pozwalają Tillor samemu wykonywać działania, na przykład tworzyć zadania lub wywoływać Twój system. Opis dla użytkowników znajdziesz w Automatyzacje. Ta strona opisuje to, co widzi integrator: wiadomość z kroku Wyślij webhook, Żądanie API na własny URL lub do API Tillor oraz sposób zbudowania przepływu, gdy zarządzasz nim przez API.

Wysyłanie webhookaKopiuj link do tej sekcji

Krok Wyślij webhook dostarcza własną wiadomość do jednego z webhooków organizacji. To to samo dostarczanie co przy zwykłych zdarzeniach webhooka, z tym samym podpisem.

WiadomośćKopiuj link do tej sekcji

Krok wysyła POST z Content-Type: application/json i tymi nagłówkami:

Treść ma tę samą kopertę co payload webhooka:

{
  "event": "automation.invoice_unpaid",
  "data": {
    "invoice": "2026-0042",
    "amountOutstanding": 125.5
  },
  "timestamp": 1735689600000,
  "traceId": "0b0f7c0e-5d3c-4c1e-9b8a-7f1e2a3b4c5d",
  "triggeredBy": null
}

Nie ma spanId. Webhook nie musi być zapisany na klucz zdarzenia: wiadomość z automatyzacji jest zawsze dostarczana na wybrany endpoint, dopóki on istnieje i jest włączony.

Jak sprawdzić podpis, opisano w Weryfikacja podpisu.

Próby i wynikKopiuj link do tej sekcji

Tillor wykonuje w ramach kroku do 5 prób, z oczekiwaniem 1, 2, 4 i 8 sekund między nimi. Próba jest udana przy statusie 2xx. Także zablokowany cel, na przykład adres wewnętrzny, liczy się jako nieudana próba.

• Jeśli któraś próba się powiedzie, przepływ kontynuuje wyjściem Powodzenie
• Jeśli wszystkie pięć się nie powiedzie, przepływ kontynuuje przez Niepowodzenie. Wiadomość jest potem jeszcze ponawiana w tle według harmonogramu z Zachowanie dostarczania i ponowienia. Jeśli taka późniejsza próba się powiedzie, nie wróci to już do wykonania, bo ono poszło już dalej

Jeśli webhook już nie istnieje lub jest wyłączony, krok nie przechodzi przez Niepowodzenie. Wykonanie kończy się wtedy ze statusem Niepowodzenie.

Żądanie API na własny URLKopiuj link do tej sekcji

Przy Żądanie API i Wyślij do ustawionym na Własny URL automatyzacja wysyła żądanie HTTP na Twój serwer.

Odpowiedź ze statusem 2xx kontynuuje przez Powodzenie, każdy inny status przez Niepowodzenie. Jeśli serwer jest nieosiągalny albo przekroczy limit czasu, wykonanie kończy się ze statusem Niepowodzenie.

Żądanie API do API TillorKopiuj link do tej sekcji

Przy Wyślij do ustawionym na Tillor API automatyzacja wywołuje API własnej organizacji. Podajesz tylko ścieżkę, na przykład /tasks, a Tillor umieszcza ją po /api/orgs/{orgId}. Dokumentacja API jest w OpenAPI.

• Tożsamość: żądanie jest wykonywane jako użytkownik Przepływ pracy organizacji. Ma on wszystkie uprawnienia w tej organizacji i nigdzie indziej. Zmiany są więc zapisane na nazwę Przepływ pracy
• Klucz niepotrzebny: Tillor sam wykonuje wywołanie, bez klucza API i bez przechodzenia przez internet
• Ścieżka: musi zaczynać się od jednego /. //, .. i \ są niedozwolone. Dozwolony jest query string, na przykład /tasks?terrainId=…&limit=1. Zmienne w ścieżce są wstawiane w postaci zakodowanej
• Zablokowane: ścieżki /automations i /automation-runs są odrzucane, także z query stringiem, wielkimi literami, końcowym / lub kodowaniem procentowym. Automatyzacja nie może zarządzać automatyzacjami
• Treść: JSON, dla POST, PUT i PATCH. Przy GET i DELETE nie jest wysyłana
• Menu wyboru: w edytorze jest Wybierz punkt końcowy API z operacjami ze specyfikacji OpenAPI. Operacji wewnętrznych tam nie ma. Gdy wybierzesz jedną, Tillor uzupełnia metodę, ścieżkę i przykładową treść
• Niepowodzenie: odpowiedź 2xx kontynuuje przez Powodzenie. Status błędu, także 404 dla nieistniejącej ścieżki, idzie przez Niepowodzenie

Odpowiedź w kolejnych krokachKopiuj link do tej sekcji

Po żądaniu dostępne są te zmienne:

Drugie żądanie API w tym samym przepływie zastępuje response. Zmienne działają tak jak w Zmienne i szablony.

Budowa przepływuKopiuj link do tej sekcji

Automatyzacje możesz też tworzyć i zmieniać przez API. Operacje są w OpenAPI pod tagiem automations. Odczyt wymaga uprawnienia automations:read, tworzenie i zmiana automations:write (albo wszystkich uprawnień). Sam użytkownik Przepływ pracy nigdy nie może ich wywołać. Wygodniej może być zbudować przepływ w edytorze i odczytać go jako przykład.

Nowa automatyzacja jest zawsze wyłączona. Włączenie przez enabled nie uda się, dopóki przepływ ma otwarte problemy, a włączonego przepływu nie można zapisać z problemami.

definition składa się z kroków (nodes), linii (edges) i opcjonalnie uwag (notes). Maksymalnie 100 kroków, 200 linii i 50 uwag.

{
  "nodes": [
    {
      "id": "trigger",
      "type": "trigger",
      "label": "",
      "position": { "x": 0, "y": 0 },
      "config": { "source": "event", "eventKey": "occupation:ended" }
    },
    {
      "id": "task",
      "type": "taskCreate",
      "label": "",
      "position": { "x": 0, "y": 190 },
      "config": { "title": "Controleer {occupation.terrain.name}", "priority": "HIGH" }
    }
  ],
  "edges": [
    { "id": "trigger:out:task", "source": "trigger", "target": "task", "sourceHandle": "out" }
  ],
  "notes": [
    {
      "id": "note_1",
      "text": "Maakt na elk vertrek een controletaak.",
      "position": { "x": 340, "y": 0 },
      "width": 240,
      "height": 140
    }
  ]
}

Uwaga (notes) to wyjaśnienie na kanwie. Nigdy nie jest wykonywana i nie ma linii. text ma maksymalnie 2000 znaków, width i height są w pikselach.

Linia ma sourceHandle: wyjście kroku, z którego wychodzi.

Każda akcja oprócz webhookSend i httpRequest dostaje dodatkowe wyjście error, gdy continueOnError w config jest ustawione na true. Bez tego ustawienia nieudana akcja zatrzymuje wykonanie. Z tym ustawieniem przepływ kontynuuje przez error, ze zmiennymi {error.message} i {error.step} dla kolejnych kroków. Wyjście skipped jest używane, gdy krok nie miał nic do zrobienia, a out jest wtedy zwykłym wyjściem.

Przy forEach wyjście each uruchamia dla każdego elementu osobne wykonanie dla kolejnych kroków, a wyjście done jest zwykłą dalszą drogą samego przepływu.

Wyjście może prowadzić do wielu kroków. Wykonanie samo idzie dalej pierwszą linią i dla każdej innej linii uruchamia osobne wykonanie z tymi samymi danymi, które działa równolegle (tak jak wyjście each w forEach). Linie tworzące pętlę są odrzucane w edytorze. Przepływ ma dokładnie jeden trigger.

Ustawienia krokówKopiuj link do tej sekcji

Pola w config to pola z edytora. Pola tekstowe przyjmują zmienne w nawiasach klamrowych.

conditions ma postać { "match": "all" lub "any", "rules": [...] }. Każda reguła to { "id", "field", "operator", "value", "values" }. operator to is, isNot, contains, greaterThan, lessThan, isOneOf, isEmpty lub isNotEmpty. values używasz tylko przy isOneOf. Pusta lista reguł przepuszcza wszystko.

Uruchamianie automatyzacji webhookiemKopiuj link do tej sekcji

Automatyzacja z triggerem webhook uruchamia się po POST na jej własny adres:

curl -X POST "https://tillor.eu/api/orgs/org_abc123/automation-hooks/aut_xxx/<token>?bron=website" \
  -H "Content-Type: application/json" \
  -d '{"email":"jan@voorbeeld.nl","aankomst":"2026-07-14"}'

• Pełny adres jest w edytorze przy triggerze albo przez GET /automations/{id}/webhook-url (z automations:read). Token jest sekretem; nagłówek do uwierzytelniania nie jest potrzebny
• Treść JSON staje się zmienną body, query string zmienną query, a moment odebrania zmienną receivedAt
• Odpowiedź 200 z { "accepted": true }, gdy tylko wykonanie zostanie uruchomione. Błędny, zastąpiony lub wyłączony adres zwraca 404, treść powyżej 100 KB zwraca 400
• Wiele wywołań w krótkim czasie nie jest odrzucanych: każde ważne wywołanie uruchamia wykonanie. Użyj Ignoruj powtórzenia przy triggerze, jeśli to samo wywołanie może przyjść dwa razy, zobacz Ignorowanie powtórzeń

Automatyzacja nie może wywołać własnego webhooka przez Żądanie API do API Tillor.

Wybór decyzji przez APIKopiuj link do tej sekcji

Zadanie kroku Poproś o decyzję ma jedną akcję na każdą opcję ustawioną w kroku. Pobierz zadanie, aby zobaczyć actions z ich id, i wybierz jedną przez POST /tasks/{id}/actions/{actionId}/choose. Jeśli opcja wymaga notatki, wyślij ją jako { "note": "..." }. Wybór jest ostateczny: kończy zadanie i prowadzi automatyzację dalej wyjściem tej opcji. Wybierać mogą przypisani współpracownicy (także przez grupę) i administratorzy. Szczegóły w OpenAPI.

Więcej do przeczytaniaKopiuj link do tej sekcji

• Webhooki o podpisie, ponowieniach i liście zdarzeń
• HTTP API o uwierzytelnianiu i kontekście organizacji
• Zmienne i szablony jako opis dla użytkowników