Setelah checkout, aplikasi Anda memiliki pesanan dan penerima yang membutuhkan tanda terima. Aplikasi menggunakan email API untuk mengirimkan pesan. Aplikasi mencatat respons terhadap pesanan tersebut.
Pengiriman hanyalah langkah pertama. Aplikasi Anda juga membutuhkan cara untuk mencoba ulang permintaan. Aplikasi perlu mengetahui apa yang terjadi pada pesan setelah dikirim.
Bagaimana event aplikasi menjadi email?
Aplikasi Anda mengubah transaksi yang selesai atau permintaan akun menjadi operasi pengiriman. Layanan email menangani pengiriman setelah pesan dikirimkan.
Untuk tanda terima, urutannya adalah:
- Aplikasi Anda mengonfirmasi bahwa pesanan siap untuk dibuatkan tanda terima.
- Aplikasi memilih penerima dan menyediakan detail pesanan sebagai konten atau nilai template.
- Aplikasi mengirimkan permintaan dan menyimpan message ID yang dikembalikan terhadap pesanan.
- Aplikasi memperbarui catatan pengiriman saat event pengiriman tiba.
Email API dapat mendukung pesan transaksional maupun pemasaran. Menggunakan API tidak menjadikan konten promosi sebagai transaksional atau menghapus kewajiban CAN-SPAM.
Apa arti respons yang berhasil?
Respons pengiriman yang berhasil mencatat apa yang diterima oleh layanan. Ini terpisah dari keputusan server email penerima selanjutnya.
Status 202 HTTP berarti permintaan diterima untuk diproses. Pemrosesan belum selesai, sehingga respons tersebut tidak dapat memastikan pengiriman.
Respons yang tepat bergantung pada API. Send endpoint Bird, misalnya, mengembalikan pesan yang diantrikan dengan id. Simpan ID tersebut bersama pesanan atau event akun agar hasil selanjutnya dapat dicocokkan dengan permintaan asli.
Jika validasi gagal, Bird mengembalikan 422 dengan error yang menjelaskan mengapa permintaan ditolak.
Bagaimana percobaan ulang menghindari pesan duplikat?
Idempotency key mengidentifikasi satu operasi pengiriman logis di seluruh percobaan ulang. API yang mendukungnya dapat mengenali permintaan yang diulang alih-alih membuat pengiriman baru.
Misalnya, tanda terima untuk pesanan 8472 dapat menggunakan key receipt/order-8472. Coba ulang permintaan yang sama dengan key tersebut jika koneksi terputus sebelum Anda menerima respons.
Key baru mengidentifikasi operasi yang berbeda. Oleh karena itu, aplikasi Anda perlu menyimpan key asli di seluruh percobaan ulang dan restart.
Idempotency memiliki jendela retensi yang ditentukan oleh penyedia. Setelah jendela tersebut berakhir, key yang sama dapat diproses sebagai permintaan baru.
Bagaimana webhook melaporkan pengiriman?
Webhook mengirimkan event ke aplikasi Anda saat status pesan berubah. Ini memungkinkan aplikasi Anda memperbarui catatannya setelah respons API awal.
Event email Bird membedakan hasil-hasil berikut:
| Event | Apa yang dinyatakannya |
|---|---|
email.delivered | Server email penerima menerima tanggung jawab atas pesan |
email.deferred | Kegagalan pengiriman sementara akan dicoba ulang |
email.bounced | Server penerima menolak pengiriman |
email.rejected | Pesan tidak mencapai percobaan pengiriman |
Penerimaan oleh server tidak memastikan pesan masuk ke inbox atau dibaca. Server penerima juga dapat melaporkan bounce setelah menerima pesan.
Handler webhook Anda harus memverifikasi tanda tangan pengirim dan menangani pengiriman duplikat. Kontrak webhook Bird memerlukan deduplikasi menggunakan webhook-id.
Apa yang diubah oleh template?
Template tersimpan memisahkan konten pesan yang dapat digunakan ulang dari nilai yang disediakan untuk setiap pengiriman. Aplikasi Anda dapat menyediakan nomor pesanan dan nama pelanggan tanpa menyusun seluruh body email.
Dengan template Bird, pengiriman menyebutkan template yang dipublikasikan dan menyediakan parameternya. Template menyediakan subjek dan body.
Template tidak menentukan kapan pesanan selesai atau apakah reset kata sandi diotorisasi. Keputusan tersebut tetap ada di aplikasi Anda.
Apa perbedaannya dengan relay SMTP atau platform pemasaran?
HTTP API dan relay SMTP adalah antarmuka pengiriman yang berbeda. Platform pemasaran juga mengelola pekerjaan kampanye, seperti memilih audiens dan menjadwalkan pengiriman.
| Antarmuka atau produk | Apa yang disediakan aplikasi Anda |
|---|---|
| Email API | Permintaan HTTP terstruktur yang berisi penerima dan konten atau template |
| Relay SMTP | Percakapan SMTP yang mengirimkan penerima dan pesan email terformat |
| Platform pemasaran | Konten kampanye, pemilihan audiens, dan instruksi pengiriman |
SMTP mendefinisikan pertukaran untuk mengirimkan pesan dan penerimanya. Protokol ini dapat membawa email transaksional atau pemasaran.
Relay SMTP Bird dan HTTP API menggunakan produk pengiriman yang sama, termasuk event dan penanganan supresi. Memilih SMTP tidak menghilangkan kemampuan tersebut.
Bagaimana cara mengirim email transaksional melalui Bird?
Anda memanggil POST /v1/email/messages dengan pengirim terverifikasi, penerima, dan konten inline atau template yang dipublikasikan. Atur category: "transactional" untuk email operasional. Responsnya adalah 202 Accepted dengan message ID; pengiriman berlanjut secara asinkron.
Gunakan Idempotency-Key untuk setiap pengiriman logis. Bird menyimpan respons yang selesai selama tiga jam. Percobaan ulang setelah jendela tersebut dapat membuat pesan baru, jadi simpan catatan Anda sendiri atas event bisnis yang telah selesai.
Berlangganan event email dan cocokkan email_id serta recipient_id dengan catatan Anda. Pesan dengan banyak penerima memiliki hasil terpisah untuk setiap penerima.
Untuk pemilihan penyedia, checklist layanan email transaksional mencakup kemampuan pengiriman dan operasional yang perlu dibandingkan.