Wysyłaj e-maile po zdarzeniach w Stytch

Połącz Stytch, aby wysyłać e-maile spójne z marką, gdy rejestruje się użytkownik B2C lub gdy członek dołącza do organizacji B2B. Brew obsługuje 7 typów zdarzeń Stytch z produktów Consumer (B2C) i B2B.

Za uwierzytelnianie nadal odpowiada Stytch. Brew tylko nasłuchuje zdarzeń oraz tworzy i wysyła e-maile, które po nich następują.

• E-maile powitalne dla użytkowników B2C: Stytch wysyła zdarzenie direct.user.create, gdy powstaje nowy użytkownik Stytch B2C.
• Onboarding zespołów B2B: Stytch wysyła zdarzenie direct.member.create, gdy członek dołącza do organizacji. Zdarzenie zawiera pole role.
• Powiadomienia o zmianie roli: Stytch wysyła zdarzenie direct.member.update, gdy zmienia się rekord członka, np. jego rola lub imię i nazwisko.
• Powiadomienia przy offboardingu: Stytch wysyła zdarzenia direct.user.delete i direct.member.delete, gdy użytkownik lub członek zostanie usunięty. Są one przetwarzane tylko wtedy, gdy Brew zna już tego użytkownika lub członka i jego prawdziwy adres e-mail.
• Synchronizacja profilu: zdarzenie direct.user.update aktualizuje kontakt w Brew, gdy zmieniają się dane użytkownika B2C.

Stytch przypisuje każdemu zdarzeniu źródło. Brew przetwarza zdarzenia ze źródła direct, które pochodzą z wywołań API i SDK wykonywanych przez Twoją aplikację. Zdarzenia z panelu Stytch i z SCIM są zapisywane jako nieobsługiwane i nigdy nie uruchamiają automatyzacji, więc zmiana wprowadzona przez operatora w panelu Stytch nie wysyła e-maili do klientów.

Zdarzenie direct.organization.create nie zawiera odbiorcy. Brew zapisuje je jako zdarzenie z nieustalonym odbiorcą i nie uruchamia automatyzacji. Aby wysłać e-mail do konkretnej osoby, użyj zdarzenia direct.member.create, które zawiera adres członka.

Zdarzenia usunięcia zawierają tylko identyfikator. Brew szuka adresu e-mail, który wcześniej otrzymał dla tego użytkownika lub członka w bieżącym połączeniu. Jeśli go nie ma, zdarzenie jest zapisywane z nieustalonym odbiorcą.

• Otwórz Integracje, wybierz Stytch i kliknij „Wygeneruj adres URL webhooka”.
• Wybierz typ projektu zgodny z Twoim projektem w Stytch: Consumer (B2C) lub B2B.
• W panelu Stytch otwórz Webhooks i dodaj endpoint z adresem URL Brew.
• W projektach B2C włącz zdarzenia direct.user.create, direct.user.update i direct.user.delete. W projektach B2B włącz zdarzenia direct.organization.create, direct.member.create, direct.member.update i direct.member.delete.
• Wyświetl sekret podpisujący endpointu (zaczyna się od whsec_), wklej go w Brew i kliknij Połącz. Brew weryfikuje każde dostarczenie zgodnie ze specyfikacją Standard Webhooks (Svix).
• W Stytch otwórz kartę Testing endpointu, wybierz direct.user.create lub direct.member.create i kliknij Send Example. Status w Brew zmieni się z „Czeka na zdarzenie testowe” na „Połączona”. Przykładowe zdarzenie służy tylko do weryfikacji webhooka. Brew nie dodaje kontaktu i nie uruchamia automatyzacji.
• Kliknięcie Połącz tworzy wyzwalacze dla wszystkich 7 zdarzeń. Nie ma przełącznika do włączania lub wyłączania zdarzeń.
• Utwórz automatyzację, wybierz dla niej zdarzenie Stytch i wyślij test, dopóki jest jeszcze wersją roboczą. Po nadejściu pasującego zdarzenia uruchamiają się tylko aktywne automatyzacje.

Zdarzenia direct.user.create, direct.user.update i direct.user.delete pochodzą z projektów B2C. Zdarzenia organizacji i członków pochodzą z projektów B2B.

Brew obsługuje 7 typów zdarzeń:

• direct.user.create
• direct.user.update
• direct.user.delete
• direct.organization.create
• direct.member.create
• direct.member.update
• direct.member.delete

Każde zweryfikowane zdarzenie z prawdziwym adresem e-mail tworzy lub aktualizuje kontakt w Brew dopasowany po adresie e-mail – niezależnie od tego, czy jakaś automatyzacja korzysta z tego zdarzenia. Jeśli zdarzenie zawiera odpowiednie dane, Brew ustawia imię, nazwisko i pole stytch_project.

Zdarzenia B2C ustawiają pole stytch_user_id. Zdarzenia członków ustawiają pola stytch_member_id, stytch_organization_id i stytch_org_role. Zdarzenia usunięcia ustawiają pole stytch_account_status na deleted. Brew nie usuwa kontaktu.

W tagach personalizacji korzystaj ze schematu danych zadeklarowanego dla wybranego zdarzenia. Każde zdarzenie zawiera pola email, firstName, lastName i createdAt, jeśli są dostępne. Zdarzenia członków dodają pole role, a zdarzenie direct.organization.create – pola organizationName i organizationSlug. Pole createdAt to znacznik czasu uniksowego w sekundach.

Identyfikatory użytkowników, członków i organizacji Stytch nie są tagami personalizacji. Zamiast tego trafiają do kontaktu jako pola stytch_*.

Konto w Stytch nie oznacza zgody na e-maile marketingowe. Zapisuj zgodę przy rejestracji i sprawdzaj ją przed wysyłkami promocyjnymi.

Nie. Wiadomości uwierzytelniające wysyłane przez Stytch pozostają bez zmian. Brew uruchamia automatyzacje na podstawie wymienionych tu zdarzeń webhooków – już po tym, jak Stytch utworzy, zaktualizuje lub usunie użytkownika albo członka.

Odebranie zdarzenia i wysłanie e-maila to osobne kroki. Upewnij się, że pasująca automatyzacja jest aktywna, a potem przejrzyj jej filtry i historię uruchomień, sprawdź, czy odbiorca może otrzymać wiadomość, i skontroluj domenę wysyłkową. Zdarzenia wysłane przyciskiem Send Example, zdarzenia z panelu Stytch i z SCIM oraz zdarzenia bez znanego odbiorcy nigdy nie uruchamiają automatyzacji.

• Brew nie może tworzyć ani zmieniać w Stytch użytkowników, członków ani organizacji.
• Jeśli Stytch przy każdym dostarczeniu zgłasza błąd 401, sekret podpisujący w Brew nie pasuje do sekretu endpointu. Wyświetl aktualny sekret i połącz Stytch ponownie. Brew wymaga, aby sekret zaczynał się od whsec_ i miał co najmniej 24 znaki.
• Sprawdź zgody i cel każdego e-maila. Synchronizacja użytkowników Stytch nie upoważnia do wysyłek promocyjnych.

• Instrukcja konfiguracji Stytch
• Zbuduj automatyzację
• Tagi personalizacji
• Co możesz wysyłać przez Brew
• Webhooki Stytch