Powiadomienia zewnętrzne
Rejestruj e-maile wysłane klientowi przez Twój własny system, aby pracownicy widzieli je w Tillor
Ostatnio zaktualizowano
Czy Twój system sam wysyła e-maile do klientów (newsletter, potwierdzenie rezerwacji, przypomnienie)? Zarejestruj je w Tillor. Pracownicy widzą je przy kliencie, na fakturze i w przeglądzie Powiadomienia, obok powiadomień wysyłanych przez sam Tillor.
Tillor niczego nie wysyła: rejestrujesz wiadomość, która została już wysłana. Powiadomienia zewnętrzne zawsze mają w aplikacji etykietę Zewnętrzne z nazwą Twojego źródła, dzięki czemu nigdy nie zostaną wzięte za powiadomienie Tillor.
Dostęp
Użytkownik stojący za kluczem API potrzebuje w organizacji jednego z tych uprawnień. Administrator przyznaje je w uprawnieniach użytkowników organizacji, w grupie Powiadomienia (Rejestrowanie powiadomień zewnętrznych i Zarządzanie powiadomieniami zewnętrznymi innych).
| Permissie | Wat mag je |
|---|---|
notifications:external:write | Rejestrowanie powiadomień oraz aktualizowanie lub usuwanie własnych rejestracji |
notifications:external:manage-others | Także aktualizowanie lub usuwanie rejestracji innych użytkowników lub integracji |
Jeden użytkownik na integrację
Własność jest przypisana do użytkownika klucza API. Używaj dla każdej integracji osobnego użytkownika (usługowego), wtedy jedna integracja nigdy nie zmieni powiadomień innej.
Endpointy
Wszystkie ścieżki są pod /api/orgs/:orgId. Dokładne schematy: OpenAPI, tag notifications.
| Method | Pad | Beschrijving |
|---|---|---|
| POST | /notifications/external | Rejestracja powiadomienia |
| PATCH | /notifications/external/{id} | Aktualizacja statusu, czasów lub treści |
| DELETE | /notifications/external/{id} | Trwałe usunięcie |
| GET | /notifications?source=EXTERNAL | Lista zarejestrowanych powiadomień (filtruj też po externalSource, externalReference, customerId, invoiceId) |
| GET | /notifications/{id} | Pobranie jednego powiadomienia |
Powiadomień wysłanych przez sam Tillor nie możesz przez te endpointy zmienić ani usunąć; zwracają 404.
Rejestrowanie
curl -X POST "https://tillor.eu/api/orgs/org_abc123/notifications/external" \
-H "x-api-key: tkn_xxx" \
-H "Content-Type: application/json" \
-d '{
"externalSource": "mailchimp",
"externalReference": "campaign-42:member-9f3a",
"name": "Boekingsbevestiging",
"customerId": "clx789...",
"channel": "EMAIL",
"status": "SENT",
"sentAt": "2026-09-19T08:15:00Z",
"email": {
"to": "jan@voorbeeld.nl",
"from": "Recreatiepark Het Meer <info@recreatiepark-het-meer.be>",
"subject": "Je boeking is bevestigd",
"htmlBody": "<p>Dag Jan, ...</p>",
"attachments": [{ "filename": "bevestiging.pdf", "contentType": "application/pdf", "size": 48211 }]
}
}'Wszystkie pola i limity znajdziesz w OpenAPI. Te pola mają reguły, które warto znać z góry:
| Veld | Regel |
|---|---|
externalSource | Nazwa Twojego systemu małymi literami, cyfry, ., _ lub - (np. mailchimp). Pracownicy widzą tę nazwę przy powiadomieniu |
externalReference | Twój własny identyfikator tej wiadomości, unikalny w obrębie externalSource |
name | Krótka etykieta dla pracowników (np. „Boekingsbevestiging”). Można po niej wyszukiwać |
customerId / invoiceId | Przynajmniej jedno z nich. Określa, gdzie powiadomienie się pojawi. Jeśli wyślesz tylko invoiceId, Tillor powiąże też klienta tej faktury. Nieznany identyfikator lub faktura innego klienta zwraca 400 |
status | SENT, FAILED, BOUNCED lub COMPLAINED. Bez sentAt przy SENT Tillor używa momentu rejestracji |
sentAt, readAt, clickedAt | ISO 8601 ze strefą czasową, np. 2026-09-19T08:15:00Z. Inne wartości są odrzucane |
email.attachments | Tylko metadane (filename, contentType, size). Same pliki nie są zapisywane |
Bezpieczne ponawianie
POST jest idempotentny dla externalSource + externalReference. Jeśli wyślesz tę samą kombinację ponownie (na przykład po przekroczeniu czasu), otrzymasz istniejące powiadomienie i nic się nie zmieni. Aby coś zmienić, użyj PATCH.
Bez danych osobowych w externalReference ani name
externalSource, externalReference i name są zapisywane bez szyfrowania, ponieważ można po nich wyszukiwać. Używaj identyfikatora technicznego, nie adresu e-mail ani nazwiska. externalReference zawierający @ jest odrzucany. Odbiorca, temat, treść i załączniki są natomiast zapisywane w postaci zaszyfrowanej.
Aktualizacja i usuwanie
Przy PATCH wysyłaj tylko pola, które się zmieniają, na przykład gdy e-mail po czasie zostanie odrzucony:
curl -X PATCH "https://tillor.eu/api/orgs/org_abc123/notifications/external/NOTIFICATION_ID" \
-H "x-api-key: tkn_xxx" \
-H "Content-Type: application/json" \
-d '{ "status": "BOUNCED", "errorMessage": "Mailbox bestaat niet" }'DELETE usuwa powiadomienie trwale, razem z treścią. Użyj go także, aby spełnić żądanie usunięcia danych (RODO).
PATCH, który niczego nie zmienia, nic nie robi: brak zmiany, brak zdarzenia. Jeśli zmienisz treść (etykietę, odbiorcę, nadawcę, temat, tekst, HTML lub załączniki) albo usuniesz powiadomienie, zostanie to zapisane w dzienniku aktywności klienta lub faktury, wraz z użytkownikiem, który to zrobił. Aktualizacje statusu, readAt lub clickedAt tam nie trafiają, dzięki czemu możesz dalej synchronizować otwarcia i kliknięcia.
HTML i prywatność
Tillor pokazuje pracownikom HTML tak, jak otrzymał go klient, ale traktuje go jak treść niezaufaną:
- Przy zapisie usuwane są skrypty, formularze, iframe, embedy i atrybuty zdarzeń (
onclick, ...). Linki otwierają się w nowej karcie - Podgląd działa w odizolowanej ramce, bez skryptów i bez dostępu do sesji Tillor
- Zewnętrzne obrazy i czcionki nie ładują się automatycznie, więc otwarcie powiadomienia nie uruchamia piksela śledzącego. Pracownik może załadować obrazy dla każdego powiadomienia osobno
Nie licz więc na to, że śledzenie „otwarcia” w Twoim systemie zadziała, gdy pracownik obejrzy powiadomienie.
Czego Tillor nie robi z powiadomieniami zewnętrznymi
- Nie wysyła ich (ponownie) i nie ponawia automatycznie
- Nie pobiera aktualizacji statusu od Twojego dostawcy poczty: status aktualizujesz sam przez
PATCH - Nie wlicza ich do list Nieudane powiadomienia, Odrzucone powiadomienia i Oczekujące powiadomienia ani do liczników na górze przeglądu powiadomień, ponieważ Tillor nie może zweryfikować Twojego statusu. Są natomiast w sekcji Ostatnia komunikacja
Webhooki i SSE
| Event | Wanneer |
|---|---|
notification-delivery:updated | Przy rejestracji i przy każdym PATCH, który coś zmienia. Zawiera pełne powiadomienie |
notification-delivery:deleted | Przy DELETE. Zawiera tylko id, source, externalSource, externalReference, customerId i invoiceId |
Pole source to EXTERNAL dla Twoich rejestracji i INTERNAL dla powiadomień Tillor. Filtruj po nim, jeśli chcesz pomijać własne zdarzenia. Zobacz Webhooki i SSE.