Sign inGet Started
Rozpocznij
Przewodniki
Referencja API
SDK
CLI
Baza wiedzy
Changelog

Szablony e-mail

Szablon to temat i treść wiadomości e-mail, które zapisujesz raz i wysyłasz wielokrotnie. Części, które się zmieniają, zapisujesz jako symbole zastępcze {{ variable }}, publikujesz szablon, a potem wysyłasz go po slugu zamiast wklejać ten sam HTML w każde wywołanie API. Szablon należy do Twojego obszaru roboczego.

Twórz szablony i zarządzaj nimi w Email > Templates, przez /v1/email/templates, za pomocą bird CLI lub przez serwer MCP. Typowane metody są dostępne w SDK TypeScript, Python, PHP i Go w ramach email.templates. Pełne schematy żądań i odpowiedzi znajdziesz w dokumentacji API. Opublikowany szablon wysyłasz przez standardowy endpoint wysyłki.

Co zawiera szablon

Każdy szablon ma dwie nazwy i każda z nich pełni inną funkcję:

  • slug to nazwa, po której wysyłasz szablon, na przykład welcome-email. Wybierasz ją przy tworzeniu szablonu i nie można jej później zmienić. Slug może zawierać małe litery, cyfry, łączniki i podkreślenia, musi zaczynać się i kończyć literą lub cyfrą i może mieć maksymalnie 63 znaki. Dwa prefiksy są zarezerwowane: bird_, przeznaczony dla naszych wbudowanych szablonów, oraz emt_, który jest formatem używanym dla identyfikatorów szablonów. W dashboardzie to pole nosi nazwę Alias.
  • name to dowolna etykieta wyświetlana. Domyślnie przyjmuje wartość sluga i możesz ją zmienić w dowolnym momencie. Nic nie jest rozwiązywane przez nazwę, więc zmiana nazwy szablonu na potrzeby wyświetlania nigdy nie psuje wysyłki.

Oprócz nich szablon ma stały identyfikator emt_, który nie zmienia się przez cały okres istnienia szablonu. Ma też category, czyli marketing lub transactional, oraz źródło tworzenia source: html, gotowy kod znaczników, który dostarczasz, opcjonalnie spersonalizowany za pomocą Liquid. Kategoria i źródło są ustalane przy tworzeniu szablonu.

Udostępniamy katalog wbudowanych szablonów, a ich slugi zaczynają się od bird_. Wbudowany szablon nie należy do żadnego obszaru roboczego, nie można go edytować i zawsze jest gotowy do wysłania. Skopiuj go do swojego obszaru roboczego, aby stał się Twój, i stanie się zwykłym szablonem, który możesz edytować. Kopia pojawia się jako nieopublikowany szkic, który dziedziczy kategorię, źródło i ustawienia językowe oryginału, więc opublikuj go przed wysłaniem.

Szkice i opublikowane wersje

Każdy szablon ma dokładnie jedną wersję roboczą, czyli kopię, którą edytujesz. Ma też dowolną liczbę opublikowanych wersji, z których każda jest numerowana (1, 2, 3, i tak dalej) i nigdy nie jest zmieniana po utworzeniu. Edycja zmienia wersję roboczą w miejscu. Publikacja tworzy migawkę bieżącej wersji roboczej, zamienia ją w kolejną numerowaną wersję i sprawia, że wysyłki korzystają właśnie z niej. Sama wersja robocza pozostaje edytowalna, więc możesz kontynuować pracę nad następną.

Zasada, która ma znaczenie przy wysyłce, brzmi tak: wysyłka zawsze korzysta z opublikowanej wersji szablonu, a wersja robocza nigdy nie jest wysyłana samodzielnie. Możesz dalej edytować wersję roboczą, podczas gdy stabilna wersja jest wciąż wysyłana, a opublikować, gdy zmiana będzie gotowa. Opublikowanie nowej wersji zmienia to, co renderują późniejsze wysyłki. Wysyłka, która została już zaakceptowana, nie jest dotknięta publikacją, która nastąpi później.

Karta Wersje szablonu z wierszem wersji roboczej oraz opublikowanymi wersjami v3, v2 i v1 wraz z datami utworzenia i publikacji

Wersje obsługują jeszcze dwa działania. Odrzuć zmiany wersji roboczej, aby zresetować ją do aktualnie opublikowanej wersji. Albo przywróć wcześniejszą wersję, aby ponownie uczynić wcześniejszą opublikowaną wersję tą, z której korzystają wysyłki. Przywrócić można tylko wersję, która była opublikowana, nigdy samą wersję roboczą. Przywrócenie zastępuje wersję roboczą treścią tej wersji, więc wszystko niezapisane w wersji roboczej jest tracone, a dalsze edytowanie rozpoczyna się od przywróconej wersji. Przywrócenie nie tworzy nowej wersji.

Aby wybrać istniejący obraz, potrzebujesz dostępu do odczytu biblioteki mediów obszaru roboczego. Aby przesłać, wkleić lub upuścić nowy obraz, potrzebujesz dostępu do zapisu. Jeśli opcja Insert image jest wyłączona albo nie możesz przeglądać lub przesyłać, poproś administratora obszaru roboczego o odpowiednie uprawnienie do biblioteki mediów. Samo uprawnienie do edycji szablonów nie daje dostępu do biblioteki mediów.

W dashboardzie wybierz Visual > Insert image, aby przeszukać bibliotekę mediów lub przesłać obraz PNG, JPEG, GIF lub WebP o rozmiarze do 5 MB. Statyczne pliki WebP są konwertowane do PNG lub JPEG. Zaznacz obraz, aby ustawić jego Image description, szerokość wyświetlania, wyrównanie i link. Oznacz obraz jako Decorative image tylko wtedy, gdy nie niesie żadnej informacji; obraz z linkiem wymaga opisu wyjaśniającego cel linku. Każdy język przechowuje własne opisy obrazów i układ.

Użyj Replace image, aby zmienić wybrany obraz, zachowując jego opis, link, szerokość i wyrównanie. Możesz też wkleić lub upuścić jeden plik graficzny do edytora wizualnego. Poczekaj na zakończenie przesyłania lub anuluj je, zanim zapiszesz lub wyślesz test. Sprawdź podgląd, a następnie otwórz More actions > Test email, aby wysłać bieżącą treść do siebie. Code pozostaje dostępny do edycji HTML.

Usunięcie obrazu z biblioteki mediów nie usuwa go z już wysłanych wiadomości e-mail. Zamiana obrazu używa nowego URL-a, więc wcześniejsze wiadomości nadal wyświetlają oryginał.

Zapis jest chroniony numerem rewizji. Wyślij revision, który ostatnio odczytałeś dla zapisywanego języka. Jeśli ktoś inny zmienił ten język w międzyczasie, zapis jest odrzucony jako konflikt zamiast nadpisywania jego pracy. Pomiń revision, aby zapisać bezwarunkowo. Publikacja i przywracanie korzystają z revision wersji roboczej w ten sam sposób.

Treść w więcej niż jednym języku

Szablon przechowuje treść w maksymalnie 25 językach, każdy z własnym tematem i treścią, oznaczony kodem BCP-47, takim jak en lub pt-BR. Jeden język jest domyślny dla szablonu. Publikacja szablonu publikuje jednocześnie każdy język, który zawiera. Nie można opublikować jednego języka osobno, więc wszystkie muszą być najpierw ukończone. Każdy język wymaga tematu i treści, a domyślny język szablonu musi być jednym z języków, które wypełniłeś. Jeśli czegokolwiek z tego brakuje, nic nie jest publikowane, a błąd informuje, czego brakuje w każdym języku, abyś mógł naprawić wszystko za jednym razem. Nie musisz kończyć każdego języka od razu: opublikuj te, które są gotowe, a resztę dodaj później.

Język wymaga treści HTML. Możesz pominąć jego text: publikacja wtedy automatycznie tworzy alternatywę tekstową z HTML, więc otrzymujesz obie części bez pisania drugiej samodzielnie.

Każdy język może też zawierać tekst podglądu, czasem nazywany preheaderem: linię, którą skrzynka odbiorcza wyświetla po temacie na liście wiadomości. Jest opcjonalny, ma do 255 znaków i przyjmuje te same symbole zastępcze {{ variable }} co temat. Pomiń go, a skrzynka odbiorcza wyświetli pierwszą linię treści wiadomości, co rzadko jest tym, co byś wybrał. Publikowanie odrzuca tekst podglądu w języku, którego treść nie ma części HTML, ponieważ klient poczty odczytuje linię podglądu wyłącznie z ukrytego znacznika HTML, i odrzuca {{ bird.unsubscribe_url }} w tekście podglądu z tego samego powodu, dla którego temat nie może go zawierać: żadne z nich nie jest miejscem, w którym może znajdować się link.

Dwa ustawienia obsługują wysyłkę, która nie wskazuje języka, dla którego szablon ma treść, i chronią przed różnymi błędami:

UstawienieCo kontroluje
on_missing_languageCo się dzieje, gdy wysyłka żąda języka, którego szablon nie ma. fallback, wartość domyślna, zwraca najbliższe dopasowanie. Najpierw próbuje szerszej formy tego samego języka, więc zapisany pt może obsłużyć żądanie pt-BR. Następnie stosuje domyślny język szablonu. fail zamiast tego odrzuca wysyłkę, dla treści, gdzie wysłanie niewłaściwego języka jest gorsze niż niewysłanie w ogóle.
language_source_requiredCzy wysyłka w ogóle musi wskazywać język. Domyślnie jest wyłączone, więc wysyłka bez wskazania języka otrzymuje język domyślny. Włącz to ustawienie, a taka wysyłka zostanie odrzucona. Broadcast wskazuje jeden język dla całej grupy odbiorców, więc szablon, w którym to ustawienie jest włączone, wymaga wybrania języka, zanim broadcast będzie mógł wysłać.

Możesz ustawić te dwa niezależnie. Samo fail działa tylko wtedy, gdy wysyłka wskazuje język, którego nie mamy, więc wysyłka bez wskazania języka przechodzi. Włącz oba ustawienia razem, gdy chcesz, żeby każda wysyłka celowo wskazywała język.

Personalizacja za pomocą zmiennych

Zapisz symbole zastępcze {{ variable }} w temacie, tekście podglądu i treści. Zbieramy je automatycznie ze wszystkich języków, więc nigdy nie musisz ich deklarować osobno. Prefiks symbolu zastępczego rozróżnia dwa rodzaje. Ścieżka zaczynająca się od bird. odczytuje nasze dane, czyli rekord kontaktu lub link do wypisania się. Wszystko inne jest parametrem, któremu nadajesz wartość podczas wysyłki.

Nazwa parametru to pojedyncze słowo, jak {{ animal }}. Nazwa z kropkami sięga do struktury, której parametr nie posiada, więc opublikowanie takiej nazwy jest odrzucane: zapisz wartość jako osobny parametr albo odczytaj dane kontaktu za pomocą bird.contact.<attribute>.

W przypadku pojedynczego wysłania lub wsadu wartość parametru pochodzi z obiektu template.parameters wysyłki, pod kluczem odpowiadającym jego nazwie. Jeden zestaw wartości obejmuje wszystkich odbiorców danej wysyłki. bird to jedyna nazwa, której nie można tam użyć: klucz template.parameters o nazwie bird jest odrzucany z błędem 422.

Broadcast nie ma obiektu parameters, więc jego treść może używać tylko placeholderów bird.. bird.contact.<attribute> jest wypełniane na podstawie właściwości kontaktu każdego odbiorcy, co personalizuje treść dla poszczególnych odbiorców. Każda właściwość kontaktu jest dostępna pod własnym kluczem, a także trzy wbudowane pola: first_name, last_name i email.

Przykład kodu
Hi {{ bird.contact.first_name }},

Każdy parametr w szablonie wymaga wartości w momencie wysyłki. W przeciwnym razie API zwraca 422 z nazwą brakującego parametru. Podawaj wartości parametrów dla wszystkich języków, ponieważ wybrany język może zależeć od ustawień zastępczych. Brakująca właściwość kontaktu jest renderowana jako pusta wartość, więc dodaj wartość domyślną dla treści widocznych przez klienta: {{ bird.contact.first_name | default: "there" }}.

Broadcast jest bardziej restrykcyjny w kwestii akceptowanych nazw, ponieważ jedynym źródłem wartości placeholderów są właściwości kontaktu. Jego placeholdery bird.contact.* mogą wskazywać tylko wbudowane pole lub właściwość kontaktu zarejestrowaną w obszarze roboczym. Każdy inny placeholder, w tym parametr, jest taki, którego broadcast nie ma czym wypełnić. Wysyłka jest odrzucana, a błąd wskazuje placeholder.

Zarchiwizowanie właściwości usuwa ją z selektora właściwości w edytorze. Nowe wersje szablonu, które ją odczytują, nie mogą zostać opublikowane, a błąd wskazuje tę właściwość. Szablony już opublikowane nadal wysyłają. Przywróć właściwość z archiwum, aby używać jej w nowych wersjach.

Placeholdery używają Liquid, więc filtry i sterowanie przepływem działają obok zwykłego podstawiania. Warunek {% if %} i pętla {% for %} po wartości tablicowej są dozwolone. Kilka konstrukcji jest odrzucanych przy publikowaniu, a błąd wskazuje dokładnie, co zmienić:

  • Dołączanie częściowe za pomocą {% include %} lub {% render %}.
  • Tagi increment, decrement i ifchanged.
  • Filtry money, format_date, format_time, json, inspect i type.
  • Porównywanie z empty lub blank. Użyj .size == 0 zamiast tego.
  • Bloki zagnieżdżone znacznie głębiej, niż wymaga tego rzeczywisty markup e-maila.

Szablon broadcastu nie może w ogóle używać pętli {% for %}, ponieważ broadcast wypełnia jedną wartość na właściwość kontaktu i nie ma po czym iterować. Jeśli treść wymaga pętli, wyślij ją przez API wiadomości.

Każdy szablon używa Liquid, w tym taki, który zawiera wyłącznie {{ variable }} placeholdery. Przed publikacją walidujemy temat, tekst podglądu, HTML i treść plain-text jako Liquid. Dodajemy też filtr escape do każdego wyjścia HTML, które nie kończy się jeszcze na escape lub escape_once, dzięki czemu wartość zawierająca & lub < nie może zmienić otaczającego znacznika. Zarezerwowane wyjście z linkiem rezygnacji z subskrypcji pozostaje bez zmian, aby wysyłka mogła je podstawić. Temat i treść plain-text pozostają bez modyfikacji. Ponieważ publikacja dodaje te filtry, HTML odczytany z opublikowanej wersji może nie być identyczny bajt po bajcie z tym, co przesłałeś.

Umieść pełny URL bezpośrednio w href, na przykład <a href="{{ sign_in_url }}">Sign in</a>. Nie dodawaj url_encode do całej wartości. Koduje on procentowo https://, /, ? i &, co uniemożliwia działanie wyniku jako linku bezwzględnego. Dodajemy escapowanie HTML, zachowując strukturę URL. Gdy parametr dostarcza pojedynczy komponent URL, zakoduj ten komponent jawnie: <a href="https://example.com/search?q={{ query | url_encode }}">Search</a>.

Podgląd przed publikacją

Wyrenderuj szablon z przykładowymi wartościami i otrzymaj z powrotem temat oraz treść HTML i plain-text, które wysyłka dostarczyłaby. Podgląd korzysta z naszego lokalnego renderera Liquid i domyślnie renderuje wersję roboczą, co pozwala sprawdzić zmianę przed jej opublikowaniem. Może też wyrenderować opublikowaną wersję. Działa zarówno z Twoimi szablonami, jak i z wbudowanymi, i nic nie jest wysyłane.

Możesz też przekazać treść samodzielnie, zamiast odczytywać wersję roboczą. Przekaż temat i treści, a zostaną wyrenderowane dokładnie tak jak wersja robocza, co pozwala edytorowi wyświetlać zmianę w trakcie pisania bez wcześniejszego zapisywania czegokolwiek.

Personalizacja jest uzupełniana automatycznie, więc zwrócony wynik wygląda jak gotowa treść zamiast {{ }} placeholderów. Podaj contact, a każdy bird.contact.<attribute> zostanie rozwiązany na podstawie właściwości tego kontaktu, co pozwala sprawdzić sformułowania na tle prawdziwego rekordu, zanim ktokolwiek otrzyma wiadomość. Wartości pochodzą z tej samej projekcji, której broadcast używa do uzupełniania swoich placeholderów, więc podgląd zwraca to samo, co zwróciłaby wysyłka.

Pomiń contact, a zamiast tego zostaną podstawione wartości zastępcze: Bird i Test dla imienia i nazwiska, bird.test@example.com dla adresu e-mail oraz zarejestrowany fallback każdej innej właściwości. Właściwość, do której odwołuje się treść, bez fallbacka renderuje się jako jej klucz w nawiasach kwadratowych, na przykład [loyalty_tier], co wskazuje zarówno to, że wartość jest placeholderem, jak i to, która właściwość wciąż wymaga fallbacka.

Kontakt jest odczytywany w aktualnym stanie. To sprawia, że podgląd jest właściwym narzędziem do sprawdzenia treści, którą zamierzasz wysłać, ale niewłaściwym do sprawdzenia, co zawierała wcześniejsza wysyłka. Aby odczytać, co dana wysyłka faktycznie dostarczyła, otwórz tę wiadomość w logu e-mail, który renderuje ją z wartości, które ta wysyłka niosła.

Dodaj language, aby wyrenderować konkretny język, lub pomiń go, aby użyć domyślnego języka szablonu. Odpowiedź informuje, który język został wyrenderowany, co ma znaczenie, gdy żądany język nie jest dostępny, a on_missing_language szablonu zwrócił najbliższe dopasowanie.

Jeśli wersja robocza zawiera personalizację, która zostałaby odrzucona przy publikacji, podgląd zwraca ten sam błąd, więc służy jednocześnie jako sposób na wczesne wykrywanie problemów.

W kreatorze szablonów w dashboardzie opcja Preview with contact data na dole lewego panelu wyświetla wyrenderowaną wiadomość e-mail obok edytowanej treści, zarówno w edytorze wizualnym, jak i kodowym. Selektor poniżej pozwala wybrać, czyje dane uzupełniają placeholdery, a Sample data to opisane wyżej wartości zastępcze.

Wysyłanie za pomocą szablonu

Ustaw pole template wysyłki na obiekt wskazujący szablon, albo przez id (emt_...), albo przez slug, używając dokładnie jednego z nich. Wartości zmiennych umieść w template.parameters. Dodaj language, aby wybrać konkretny język, lub pomiń to pole, aby wysłać w domyślnym języku szablonu, chyba że szablon wymaga podania języka w każdej wysyłce. Pomiń subject, html i text całkowicie, ponieważ szablon już je dostarcza.

Przykład kodu
{
  "from": "hello@yourdomain.com",
  "to": ["delivered@messagebird.dev"],
  "category": "transactional",
  "template": {
    "slug": "welcome-email",
    "parameters": { "first_name": "Jane" }
  }
}

Jedno zachowanie warte zaplanowania: kategoria szablonu jest wartością domyślną, a pole category wysyłki ją nadpisuje. Pomiń category, a wysyłka odziedziczy kategorię szablonu, więc szablon operacyjny wyśle jako transakcyjny bez powtarzania tego w każdym wywołaniu. Ustaw category, a Twoja wartość wygrywa. Reszta kontraktu po stronie wysyłki jest opisana w wysyłanie z szablonem.

Tworzenie szablonów poza dashboardem

Cały cykl życia jest dostępny poza dashboardem: przez API, SDK pod email.templates, bird CLI oraz narzędzia email_templates_* MCP. W SDK operacje na wersjach i językach znajdują się pod email.templates.versions i email.templates.versions.languages. Krok publikowania nosi tam nazwę submit i zamienia szkic w kolejną opublikowaną wersję.

Możesz przechowywać szablony we własnym repozytorium i synchronizować je w kroku budowania. Szkic i opublikowana wersja zwracają różny HTML, więc wybierz odczyt pasujący do potrzeb Twojego narzędzia:

  • Szkic zwraca dokładnie to, co zapisałeś. HTML zapisany w języku szkicu wraca bajt po bajcie z odczytu tego języka (GET /v1/email/templates/{id}/versions/{draft_version_id}/languages/{language}) oraz z odczytu wersji, łącznie z doctype, blokami <style>, komentarzami, białymi znakami, końcami linii i tekstem spoza ASCII. Zapis nie zwraca treści, więc odczytaj język ponownie, jeśli chcesz potwierdzić, co zostało zapisane.
  • Opublikowana wersja zwraca treść gotową do wysyłki. Publikowanie przepisuje HTML na trzy sposoby: każde wyjście {{ }}, które nie kończy się już na escape lub escape_once, otrzymuje filtr escape, z wyjątkiem {{ bird.unsubscribe_url }}, które pozostaje bez zmian; tekst podglądu jest wstawiany w ukryty blok tuż za otwierającym tagiem <body>, lub na samym początku, gdy HTML go nie zawiera; a puste text jest wypełniane alternatywą tekstową wygenerowaną z HTML. Odczyt tej wersji zwraca przepisaną treść, więc nie będzie się zgadzać z Twoim plikiem źródłowym.

Aby wyeksportować napisaną przez siebie treść źródłową, odczytaj szkic. Odczyt szablonu lub listowanie szablonów zwraca metadane i stan poszczególnych języków, ale nie HTML.

Poniższe przykłady używają {{ first_name }}, który jest parametrem: wysyłka dostarcza jego wartość w template.parameters, na przykład "parameters": {"first_name": "Jane"}. To pasuje do wysyłki na adres e-mail. Placeholder {{ bird.contact.first_name }} czyta zamiast tego rekord kontaktu odbiorcy, który broadcast wypełnia z właściwości kontaktu każdego odbiorcy. Wysyłka na adres e-mail nie ma rekordu kontaktu, więc odrzuca szablon czytający bird.contact.* z błędem 422 (EmailTemplateContactUnavailable).

Utwórz szablon z jego pierwszym językiem. Odpowiedź zawiera id szablonu i draft_version_id, których używają operacje na wersjach i językach. Przykład ustawia też preview_text, czyli tekst podglądu, który skrzynka odbiorcza wyświetla po temacie na liście wiadomości. Publikowanie wstawia go do HTML jako ukryty blok, co jest jednym z powodów, dla których odczyt opublikowanej wersji zwraca inny HTML niż odczyt wersji roboczej:

const template = await bird.email.templates.create({
  slug: "welcome-email",
  category: "transactional",
  source: "html",
  languages: {
    en: {
      subject: "Welcome, {{ first_name }}",
      preview_text: "Your account is ready",
      html: "<!DOCTYPE html>\n<html>\n<body>\n<p>Hi {{ first_name }}, thanks for signing up.</p>\n</body>\n</html>\n",
    },
  },
});
console.log(template.id, template.draft_version_id);

Aby zmienić język później, zapisz go ponownie za pomocą bird email templates versions languages set lub PUT pod tą samą ścieżką języka. Ciało żądania jest płaskie: subject, który jest wymagany, plus preview_text, html i text. Pole, które pominiesz, zostanie wyczyszczone. Dodaj revision, który ostatnio odczytałeś, aby odrzucić zapis, jeśli ktoś inny zmienił ten język w międzyczasie.

Układ edytora wizualnego w dashboardzie jest jednym z pól czyszczonych w ten sposób, ponieważ API, SDK ani CLI nie mogą go przesłać. Zapisanie języka zbudowanego w edytorze wizualnym zachowuje jego HTML, ale usuwa układ, więc dashboard ponownie otwiera ten język w edytorze kodu.

W kolejnych krokach TEMPLATE_ID i DRAFT_VERSION_ID zastępują id i draft_version_id zwrócone przez wywołanie tworzące. Odczytaj język wersji roboczej, aby uzyskać HTML dokładnie w takiej postaci, w jakiej jest zapisany:

const language = await bird.email.templates.versions.languages.get(
  "TEMPLATE_ID",
  "DRAFT_VERSION_ID",
  "en",
);
console.log(language.content?.html);

jq -j zapisuje ciąg znaków bez dodawania końcowego znaku nowej linii, więc plik zawiera te same bajty, które zapisał API.

Najpierw wyślij wersję roboczą z validate_only. Wykonuje te same sprawdzenia co prawdziwe zatwierdzenie we wszystkich językach i zgłasza znalezione problemy w jednej odpowiedzi, niczego nie publikując. Następnie wyślij bez validate_only, aby opublikować kolejną wersję, której będą używać wysyłki:

const templateId = "TEMPLATE_ID";
const draftVersionId = "DRAFT_VERSION_ID";
const check = await bird.email.templates.versions.submit(templateId, draftVersionId, {
  validate_only: true,
});
for (const problem of check.errors) {
  console.log(problem.language, problem.field, problem.message);
}
if (check.valid) {
  const result = await bird.email.templates.versions.submit(templateId, draftVersionId);
  console.log(result.version?.version_number);
}

Treść zatwierdzenia przyjmuje validate_only i expected_revision. Przekaż revision szablonu jako expected_revision, aby odrzucić publikację, jeśli wersja robocza zmieniła się od ostatniego odczytu.

Wyświetl listę szablonów w obszarze roboczym, aby znaleźć slug, który podaje wysyłka:

for await (const tpl of bird.email.templates.list({ scope: "workspace" })) {
  console.log(tpl.slug, tpl.name);
}

Wyślij opublikowany szablon po slugu, podając wartość w template.parameters dla każdego parametru, którego używa, tutaj first_name:

const msg = await bird.email.send({
  from: { email: "onboarding@messagebird.dev", name: "Bird" },
  to: ["delivered@messagebird.dev"],
  category: "transactional",
  template: {
    slug: "welcome-email",
    parameters: { first_name: "Jane" },
  },
});
console.log(msg.id, msg.status);

Następne kroki

  • Wysyłanie e-maili: pełna struktura wysyłki i jak pasują do niej wysyłki z szablonami
  • Kategorie: wybór między marketing a transactional w każdej wysyłce
  • bird email templates: zarządzanie szablonami z terminala
  • Dokumentacja API: pełne schematy żądań i odpowiedzi dla wszystkich osiemnastu operacji na szablonach
  • SDK: typowane metody email.templates w TypeScript, Python, PHP i Go
  • Serwer MCP: umożliwienie agentowi tworzenia i publikowania szablonów
  • Jak stworzyć szablon e-maila: film pokazujący tworzenie szablonu w dashboardzie, a następnie tworzenie kolejnego przez agenta

Powiązane zasoby

Przejdź do dokumentacji, przewodników i przykładów dotyczących tego tematu.

Wypróbuj ćwiczenie i uzyskaj brief wdrożeniowy