Skip to Content

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).

PermissieWat mag je
notifications:external:writeRejestrowanie powiadomień oraz aktualizowanie lub usuwanie własnych rejestracji
notifications:external:manage-othersTakż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.

MethodPadBeschrijving
POST/notifications/externalRejestracja powiadomienia
PATCH/notifications/external/{id}Aktualizacja statusu, czasów lub treści
DELETE/notifications/external/{id}Trwałe usunięcie
GET/notifications?source=EXTERNALLista 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:

VeldRegel
externalSourceNazwa Twojego systemu małymi literami, cyfry, ., _ lub - (np. mailchimp). Pracownicy widzą tę nazwę przy powiadomieniu
externalReferenceTwój własny identyfikator tej wiadomości, unikalny w obrębie externalSource
nameKrótka etykieta dla pracowników (np. „Boekingsbevestiging”). Można po niej wyszukiwać
customerId / invoiceIdPrzynajmniej 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
statusSENT, FAILED, BOUNCED lub COMPLAINED. Bez sentAt przy SENT Tillor używa momentu rejestracji
sentAt, readAt, clickedAtISO 8601 ze strefą czasową, np. 2026-09-19T08:15:00Z. Inne wartości są odrzucane
email.attachmentsTylko 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

EventWanneer
notification-delivery:updatedPrzy rejestracji i przy każdym PATCH, który coś zmienia. Zawiera pełne powiadomienie
notification-delivery:deletedPrzy 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.

Powiązane

  • HTTP API - Klucze API, nagłówki i limity żądań
  • Webhooki - Odbieranie zdarzeń przez HTTP POST
  • OpenAPI - Pełne schematy
Czy ta strona była pomocna?

Na tej stronie