Email API: Hướng dẫn đầy đủ về gửi email bằng lập trình (2026)

Email API cho phép ứng dụng của bạn gửi email thông qua các yêu cầu HTTP.

Nghe có vẻ đơn giản, nhưng quyết định này ảnh hưởng đến độ tin cậy của sản phẩm, tỷ lệ gửi vào hộp thư, workflow kỹ thuật, phân tích dữ liệu, tuân thủ, trải nghiệm khách hàng và vận hành hỗ trợ.

Phiên bản cũ của trang này có dàn ý đúng nhưng chưa đủ sâu. Nó so sánh các API, đưa ra một ví dụ Brevo nhanh và giải thích khi nào nên dùng API thay vì SMTP. Bản cập nhật này giữ nguyên cấu trúc đó và mở rộng thành một hướng dẫn triển khai đầy đủ, có nghiên cứu, dựa trên tài liệu và bảng giá hiện tại của Brevo, SendGrid, Mailgun, Amazon SES, Postmark cùng tài liệu messaging API của chính Tajo.

Câu trả lời nhanh

Dùng email API khi bạn cần email kích hoạt từ ứng dụng:

• Xác minh đăng ký.
• Đặt lại mật khẩu.
• Đăng nhập bằng magic link.
• Xác nhận đơn hàng.
• Thông báo giao hàng.
• Hóa đơn hoặc biên nhận.
• Lời mời dùng sản phẩm.
• Onboarding trong giai đoạn dùng thử.
• Cảnh báo mức sử dụng.
• Thông báo thanh toán thất bại.
• Nhắc gia hạn.
• Tự động hóa vòng đời dựa trên sự kiện sản phẩm.

Dùng SMTP khi hệ thống gửi chỉ hỗ trợ thông tin đăng nhập SMTP, hoặc khi bạn cần một lớp truyền tải thư chuẩn hóa cho ứng dụng cũ, plugin, máy chủ hoặc công cụ nội bộ.

Lựa chọn email API tốt nhất phụ thuộc vào stack của bạn:

Đừng chọn chỉ dựa trên mức giá quảng cáo. Chi phí email API còn bao gồm thời gian kỹ thuật, công sức tối ưu gửi thư, mô hình hóa dữ liệu, giám sát, hỗ trợ và rủi ro di chuyển nền tảng trong tương lai.

Email API và SMTP

Cả API và SMTP đều có thể gửi email. Điểm khác biệt là cách ứng dụng của bạn chuyển thông điệp cho nền tảng gửi.

SMTP là giao thức truyền thư lâu đời. Nó hoạt động với nhiều công cụ và vẫn hữu ích khi sản phẩm yêu cầu cấu hình host, port, tên đăng nhập và mật khẩu.

Email API là một giao diện HTTP. Ứng dụng của bạn gửi yêu cầu đến một endpoint kèm xác thực, người nhận, nội dung, dữ liệu mẫu, metadata và đôi khi cả thông tin lên lịch hoặc gửi theo lô.

Quy tắc thực tế: nếu bạn sở hữu mã ứng dụng, hãy bắt đầu với API. Nếu bạn cấu hình một công cụ bên thứ ba chỉ hỗ trợ SMTP, hãy dùng SMTP.

Email API hoạt động như thế nào

Một luồng gửi cơ bản có bảy bước:

1. Ứng dụng của bạn tạo một sự kiện, chẳng hạn user_signed_up hoặc order_paid.
2. Ứng dụng chọn loại thông điệp.
3. Ứng dụng nạp dữ liệu người nhận, người gửi, mẫu email và cá nhân hóa.
4. Ứng dụng gửi yêu cầu HTTP đã xác thực đến nhà cung cấp email.
5. Nhà cung cấp kiểm tra yêu cầu và đưa thông điệp vào hàng đợi.
6. Nhà cung cấp trả về phản hồi với trạng thái thành công, lỗi hoặc mã định danh thông điệp.
7. Webhook báo cáo các sự kiện gửi thành công, bounce, click, khiếu nại hoặc hủy đăng ký về hệ thống của bạn.

Yêu cầu API chỉ là một phần. Một triển khai đáng tin cậy còn cần idempotency, cơ chế thử lại, ghi log, xử lý danh sách chặn, cảnh báo và quản trị dữ liệu.

Bắt đầu nhanh: Gửi email với Brevo API

API email giao dịch của Brevo dùng một yêu cầu đã xác thực đến endpoint /v3/smtp/email. SDK và tên trường cụ thể có thể thay đổi, nên hãy dùng tài liệu API của nhà cung cấp làm nguồn chuẩn khi triển khai.

Ví dụ yêu cầu:

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

Mã production không nên hard-code API key. Hãy lưu secret trong trình quản lý secret hoặc biến môi trường, xoay vòng định kỳ, giới hạn quyền truy cập và không bao giờ để lộ trong mã frontend.

Kiến trúc email API cho production

Một tích hợp email API cho production không nên gửi trực tiếp từ mọi controller hoặc route handler.

Hãy dùng một lớp thông điệp nhỏ:

1. Sự kiện sản phẩm xảy ra.
2. Ứng dụng ghi sự kiện vào hàng đợi, job hoặc event bus.
3. Dịch vụ email ánh xạ sự kiện sang mẫu email.
4. Dịch vụ email kiểm tra sự đồng thuận của người nhận và các quy tắc chặn gửi.
5. Dịch vụ email gọi API của nhà cung cấp.
6. Dịch vụ email lưu lại message ID của nhà cung cấp.
7. Webhook cập nhật trạng thái thông điệp sau đó.

Cách này giữ mã sản phẩm gọn gàng và giúp cô lập lỗi email dễ dàng hơn.

Các trường nội bộ nên có:

• event_id.
• message_type.
• recipient_id.
• recipient_email.
• template_id.
• locale.
• provider.
• provider_message_id.
• idempotency_key.
• status.
• error_code.
• created_at.
• sent_at.
• delivered_at.

Hãy dùng idempotency key cho các thông điệp quan trọng. Một lần thử lại không nên gửi ba email đặt lại mật khẩu chỉ vì yêu cầu mạng hết thời gian chờ sau khi nhà cung cấp đã chấp nhận thông điệp đầu tiên.

So sánh các email API tốt nhất

Brevo

Brevo hữu ích khi email giao dịch là một phần của hệ thống giao tiếp khách hàng rộng hơn.

Chọn Brevo khi:

• Bạn cần email giao dịch cùng với chiến dịch, CRM, tự động hóa, SMS hoặc WhatsApp.
• Dữ liệu ecommerce cần kích hoạt thông điệp vòng đời.
• Nhắn tin marketing và sản phẩm cần dùng chung hồ sơ liên hệ.
• Người không phải lập trình viên cần truy cập mẫu email và báo cáo.
• Bạn muốn một nền tảng duy nhất thay vì nhiều công cụ rời rạc cho từng kênh.

Lưu ý:

• Sự khác biệt giữa cấu hình email marketing và email giao dịch.
• Quyền sở hữu mẫu email giữa kỹ thuật và marketing.
• Giới hạn tốc độ và ràng buộc theo gói.
• Cách dữ liệu liên hệ đồng bộ.
• Cách quy tắc hủy đăng ký và chặn gửi áp dụng cho từng loại thông điệp.

Tài liệu của Brevo bao gồm gửi giao dịch, gửi theo lô, chế độ sandbox, SMTP relay, webhook, SDK và trang tham chiếu API. Hãy dùng các tài liệu đó cho chi tiết triển khai.

SendGrid

SendGrid là lựa chọn phổ biến cho các đội ngũ muốn một email API dành cho lập trình viên đã trưởng thành với hỗ trợ ngôn ngữ và nền tảng rộng.

Chọn SendGrid khi:

• Lập trình viên muốn một email API và hệ sinh thái SDK quen thuộc.
• Bạn cần email giao dịch và marketing từ cùng một nhà cung cấp.
• Bạn đã có hạ tầng Twilio.
• Bạn cần webhook sự kiện và các cấu hình gửi chi tiết.

Lưu ý:

• Tính năng gửi vào hộp thư và hỗ trợ nào có trong gói bạn chọn.
• Cách quản lý mẫu email giữa các môi trường.
• Liệu email marketing và email giao dịch có nên dùng chung cấu trúc tài khoản hay không.

Mailgun

Mailgun xây dựng quanh việc gửi email do lập trình viên dẫn dắt và workflow ưu tiên API.

Chọn Mailgun khi:

• Đội kỹ thuật sở hữu hạ tầng email.
• Bạn cần gửi qua HTTP, dự phòng SMTP, log, định tuyến email đến và công cụ xác thực địa chỉ.
• Bạn muốn một nhà cung cấp minh bạch về vận hành gửi thư.

Lưu ý:

• Tính năng xác thực địa chỉ, phân tích và tối ưu gửi thư nào đi kèm gói.
• Thời gian lưu dữ liệu và quyền truy cập log.
• Kỳ vọng hỗ trợ trong quá trình di chuyển và warmup.

Amazon SES

Amazon SES thiên về hạ tầng.

Chọn Amazon SES khi:

• Ứng dụng của bạn đã chạy chủ yếu trên AWS.
• Bạn có nguồn lực kỹ thuật để tự chủ nhiều phần trong thiết lập.
• Bạn cần gửi khối lượng lớn theo mô hình trả theo mức dùng.
• Bạn muốn tích hợp chặt với IAM, CloudWatch, SNS, Lambda hoặc các dịch vụ AWS khác.

Lưu ý:

• Gỡ chế độ sandbox và quyền truy cập production.
• Thiết lập danh tính miền gửi.
• Xử lý bounce và khiếu nại.
• Quyết định về IP riêng.
• Giám sát và cảnh báo.
• Chi phí kỹ thuật để tự xây các tính năng mà nhà cung cấp khác có sẵn trong giao diện sản phẩm.

SES có thể rất tốt ở quy mô lớn, nhưng không phải là lựa chọn tốn ít công sức nhất cho mọi đội ngũ.

Postmark

Postmark tập trung vào email giao dịch.

Chọn Postmark khi:

• Độ tin cậy và sự rõ ràng của email giao dịch quan trọng hơn độ rộng của bộ công cụ marketing tất cả trong một.
• Bạn muốn message stream tách riêng từng loại email.
• Bạn cần mẫu email, email đến và sự kiện gửi trong một sản phẩm đơn giản.

Lưu ý:

• Các bậc giá ở khối lượng của bạn.
• Thời gian lưu trữ sự kiện và thông điệp bạn cần.
• Liệu marketing hàng loạt có nên nằm ở một stream hoặc nền tảng riêng hay không.

Tajo

Tajo phù hợp khi việc gửi email gắn với ecommerce, sự kiện khách hàng và tự động hóa kết nối Brevo.

Dùng Tajo khi:

• Sự kiện sản phẩm và ecommerce cần chảy vào Brevo.
• Dữ liệu Shopify hoặc nền tảng thương mại khác cần kích hoạt thông điệp giỏ hàng bỏ quên, đơn hàng hoặc vòng đời.
• Bạn muốn một lớp tích hợp duy nhất cho dữ liệu khách hàng, đơn hàng, sản phẩm và sự kiện.
• Bạn cần một đường gửi thông điệp giao dịch có tài liệu, kết nối với mô hình dữ liệu khách hàng rộng hơn của bạn.

Tajo không thay thế tài liệu API của nhà cung cấp. Nó giảm khối lượng công việc tích hợp để đưa đúng dữ liệu khách hàng và sự kiện vào hệ thống nhắn tin.

Khi nào nên dùng email API

Email giao dịch

Email giao dịch kích hoạt từ hành động của người dùng hoặc sự kiện hệ thống.

Ví dụ:

• Xác minh tài khoản.
• Đăng nhập bằng magic link.
• Đặt lại mật khẩu.
• Xác thực hai yếu tố.
• Lời mời dùng sản phẩm.
• Xác nhận đơn hàng.
• Biên nhận thanh toán.
• Xác nhận giao hàng.
• Cập nhật vận chuyển.
• Thông báo hoàn tiền.
• Gia hạn thuê bao.
• Cảnh báo thanh toán thất bại.
• Thông báo bảo mật.

Email giao dịch đòi hỏi độ tin cậy rất cao. Người dùng nhận ra ngay khi link đăng nhập, biên nhận đơn hàng hoặc email đặt lại mật khẩu không đến.

Xem thêm: email xác nhận đơn hàng và ví dụ email giao dịch.

Email vòng đời sản phẩm

Email vòng đời nằm giữa giao dịch và marketing.

Ví dụ:

• Onboarding trong giai đoạn dùng thử.
• Kích hoạt tính năng.
• Cột mốc mức sử dụng.
• Gợi ý nâng cấp.
• Nhắc tài khoản không hoạt động.
• Thăm hỏi từ bộ phận thành công khách hàng.
• Chuỗi gia hạn.
• Thông điệp giành lại khách hàng.

Các email này hiệu quả nhất khi kích hoạt từ dữ liệu sản phẩm thay vì lịch cố định.

Email ecommerce

Đội ngũ ecommerce thường cần cả email giao dịch và email kích hoạt từ marketing:

• Ưu đãi chào mừng.
• Giỏ hàng bỏ quên.
• Bỏ dở khi đang xem sản phẩm.
• Hàng về lại kho.
• Giảm giá.
• Gợi ý sản phẩm.
• Nhắc mua bổ sung.
• Cập nhật chương trình khách hàng thân thiết.
• Yêu cầu đánh giá.
• Quyền truy cập sớm cho khách VIP.

Với các đội ngũ dùng Shopify và Brevo, Tajo có thể giúp kết nối dữ liệu đơn hàng, khách hàng, sự đồng thuận, sản phẩm và giỏ hàng để các thông điệp đó kích hoạt từ hành vi mua sắm thực tế.

Email marketing qua API

Đừng coi email marketing chỉ là một công việc gửi bản tin hàng loạt.

Marketing kích hoạt qua API có thể hỗ trợ:

• Phân khúc dựa trên sự kiện.
• Chiến dịch cá nhân hóa.
• Chuỗi drip kích hoạt theo hành vi.
• Onboarding dẫn dắt bởi sản phẩm.
• Hành trình vòng đời theo từng tài khoản.
• Email tự động gắn với hành vi khách hàng.

Chuẩn mực tuân thủ vẫn áp dụng. Thông điệp marketing cần sự đồng thuận phù hợp, xử lý từ chối nhận và quy tắc chặn gửi.

Các tính năng API quan trọng cần tìm

Xác thực và quản lý key

Một email API nghiêm túc phải hỗ trợ API key an toàn và tài liệu xác thực rõ ràng.

Yêu cầu vận hành:

• Tách key theo môi trường.
• Giới hạn quyền truy cập key production.
• Xoay vòng key định kỳ.
• Lưu key ngoài mã nguồn.
• Ghi log việc dùng key nhưng không ghi giá trị key.
• Loại key khỏi các bản dump yêu cầu lỗi.

Mẫu email

Mẫu email giữ cho email giao dịch nhất quán.

Hãy tìm:

• Quản lý phiên bản.
• Gửi thử.
• Biến động.
• Giá trị dự phòng.
• Bản địa hóa.
• Xem trước khi hiển thị.
• Workflow phê duyệt.
• Tách mẫu staging và production.

Mẫu email không chỉ là tài sản thiết kế. Chúng là một phần của cam kết sản phẩm. Mẫu đặt lại mật khẩu, mẫu xác nhận đơn hàng hoặc mẫu hóa đơn cần rà soát nghiêm túc như giao diện ứng dụng.

Webhook

Webhook biến việc gửi thành một vòng phản hồi.

Theo dõi:

• Đã xử lý.
• Bị hoãn.
• Đã gửi thành công.
• Đã mở, cần thận trọng khi diễn giải.
• Đã click, cần thận trọng khi diễn giải.
• Bounce.
• Bị loại bỏ.
• Khiếu nại.
• Hủy đăng ký.

Hãy lưu message ID của nhà cung cấp để khớp sự kiện webhook với người dùng và sự kiện nội bộ.

Quản lý danh sách chặn gửi

Xử lý chặn gửi bảo vệ khả năng gửi vào hộp thư và sự tuân thủ.

Hệ thống cần xử lý:

• Hard bounce.
• Khiếu nại.
• Hủy đăng ký.
• Chặn thủ công.
• Địa chỉ dạng chức danh nếu chính sách của bạn loại trừ chúng.
• Liên hệ không hợp lệ.
• Yêu cầu xóa tài khoản hoặc quyền riêng tư.

Đừng bao giờ tiếp tục thử lại một địa chỉ đã lỗi vĩnh viễn chỉ vì mã sản phẩm coi việc gửi email là một tác vụ nền.

Giới hạn tốc độ và thông lượng

Kiểm tra cách nhà cung cấp xử lý:

• Giới hạn yêu cầu API.
• Thông lượng thông điệp.
• Endpoint gửi theo lô.
• Giới hạn burst.
• Giới hạn theo ngày hoặc theo tháng của gói.
• Warmup tài khoản mới.
• Warmup IP riêng.

Hãy lên kế hoạch cho các đỉnh tải. Một đợt ra mắt sản phẩm, sự cố đặt lại mật khẩu, đợt sale Black Friday hoặc thông báo bảo mật có thể tạo khối lượng gửi cao hơn nhiều so với trung bình ngày.

Phân tích và xuất dữ liệu

Báo cáo tối thiểu:

• Đã gửi.
• Đã đến hộp thư.
• Bounce.
• Bị hoãn.
• Khiếu nại.
• Hủy đăng ký.
• Hiệu suất theo mẫu email.
• Lỗi phản hồi từ nhà cung cấp.
• Sự kiện doanh thu hoặc chuyển đổi khi phù hợp.

Hãy thận trọng với chỉ số mở và click. Cơ chế bảo vệ quyền riêng tư, chặn hình ảnh và hoạt động bot có thể làm méo số liệu tương tác. Với email giao dịch, việc gửi đến thành công và hành động của người dùng thường quan trọng hơn tỷ lệ mở.

Phân tích email đến

Email đến quan trọng khi người dùng trả lời hoặc gửi nội dung vào sản phẩm.

Trường hợp sử dụng:

• Trả lời hỗ trợ.
• Email thành ticket.
• Trả lời thành bình luận.
• Workflow phê duyệt.
• Biên nhận chuyển tiếp.
• Thu lead từ email đến.

Nếu phân tích email đến nằm trong lộ trình, hãy chọn nhà cung cấp có tài liệu rõ ràng, định tuyến, kiểm soát bảo mật và xử lý tệp đính kèm.

Gửi vào hộp thư với email API

API không tự động giải quyết vấn đề gửi vào hộp thư.

Bạn vẫn cần:

• SPF.
• DKIM.
• DMARC.
• Miền gửi đã xác minh.
• Danh tính người gửi nhất quán.
• Danh sách sạch.
• Xử lý bounce.
• Xử lý khiếu nại.
• Hủy đăng ký rõ ràng cho thông điệp marketing.
• Nội dung phù hợp.
• Tần suất gửi hợp lý.
• Giám sát.

Với miền hoặc IP mới, hãy warmup dần dần. Bắt đầu với thư rủi ro thấp, tương tác cao và tăng khối lượng khi uy tín ổn định.

Tách các loại thông điệp khi có thể:

• Xác thực và bảo mật.
• Biên nhận và cập nhật đơn hàng.
• Vòng đời sản phẩm.
• Marketing.
• Khuyến mãi hàng loạt.

Đừng để một chiến dịch khuyến mãi quá mạnh tay làm hỏng việc gửi email đặt lại mật khẩu hoặc biên nhận.

Xử lý lỗi và thử lại

Lỗi email API cần phân loại rõ.

Thử lại:

• Hết thời gian chờ.
• Lỗi tạm thời từ nhà cung cấp.
• Giới hạn tốc độ, sau một khoảng chờ.
• Lỗi mạng.
• Sự cố hàng đợi tạm thời.

Không thử lại mãi:

• Địa chỉ người nhận không hợp lệ.
• API key không có quyền.
• Template ID không hợp lệ.
• Thiếu trường bắt buộc.
• Người nhận trong danh sách chặn.
• Chặn theo chính sách hoặc tuân thủ.

Dùng exponential backoff và dead-letter queue cho các thông điệp vẫn lỗi sau khi thử lại.

Mọi email quan trọng cần một đường vận hành:

• Bộ phận hỗ trợ có thể gửi lại không?
• Người dùng có thể yêu cầu lại không?
• Kỹ thuật có thể truy vết sự kiện không?
• Bạn có thấy phản hồi của nhà cung cấp không?
• Bạn có thể chứng minh nhà cung cấp đã chấp nhận thông điệp hay chưa không?

Danh sách kiểm tra triển khai email API

Dùng danh sách này trước khi ra mắt.

1. Chọn loại thông điệp và người chịu trách nhiệm.
2. Chọn nhà cung cấp API và phương án dự phòng.
3. Xác minh miền gửi.
4. Cấu hình SPF, DKIM và DMARC.
5. Tạo API key cho staging và production.
6. Lưu secret an toàn.
7. Xây dịch vụ thông điệp hoặc adapter.
8. Thêm idempotency key.
9. Thêm log có cấu trúc.
10. Xây cơ chế thử lại và dead-letter.
11. Tạo mẫu email.
12. QA cá nhân hóa và giá trị dự phòng.
13. Cấu hình webhook.
14. Lưu message ID của nhà cung cấp.
15. Xử lý bounce, khiếu nại và hủy đăng ký.
16. Xây công cụ hỗ trợ để gửi lại và tra cứu trạng thái.
17. Giám sát tỷ lệ lỗi và tỷ lệ gửi thành công.
18. Ghi lại giới hạn tốc độ và playbook xử lý sự cố.

Bảng chấm điểm chọn nhà cung cấp

Chấm điểm mỗi nhà cung cấp từ 1 đến 5:

Với nhiều đội ngũ, câu trả lời đúng không phải là “email API rẻ nhất”. Đó là nhà cung cấp giúp giảm rủi ro vận hành cho các loại email mà khách hàng phụ thuộc vào.

Sai lầm thường gặp

Tránh:

• Gửi trực tiếp từ mã ứng dụng rải rác.
• Ghi log API key hoặc toàn bộ payload chứa dữ liệu riêng tư.
• Thử lại mọi lỗi như thể chúng đều tạm thời.
• Bỏ qua message ID của nhà cung cấp.
• Quên webhook cho đến khi bộ phận hỗ trợ hỏi “email đã đến chưa?”
• Trộn email đặt lại mật khẩu và marketing hàng loạt trên cùng một đường uy tín.
• Dùng một mẫu email cho mọi ngôn ngữ.
• Bỏ qua giá trị dự phòng cho biến trong mẫu.
• Coi lượt mở là bằng chứng gửi thành công hoặc thành công của khách hàng.
• Để logic hủy đăng ký marketing chặn cả các thông điệp bảo mật tài khoản bắt buộc mà không có chính sách rõ ràng.
• So sánh nhà cung cấp chỉ bằng gói miễn phí.
• Ra mắt với khối lượng lớn mà không warmup.

Bắt đầu

Với một triển khai mới, hãy đi con đường ngắn nhất mà vẫn an toàn:

1. Bắt đầu với một thông điệp giao dịch, chẳng hạn đặt lại mật khẩu hoặc xác nhận đơn hàng.
2. Xây một adapter cho nhà cung cấp thay vì gắn chặt mã sản phẩm vào một vendor.
3. Thêm xác thực miền.
4. Thêm theo dõi trạng thái qua webhook.
5. Thêm khả năng quan sát cho bộ phận hỗ trợ.
6. Thêm mẫu email và bản địa hóa.
7. Mở rộng sang tự động hóa vòng đời và ecommerce.

Nếu đội của bạn đã dùng Brevo cho marketing và CRM, hãy bắt đầu với API giao dịch của Brevo và ánh xạ dữ liệu sự kiện bạn cần. Nếu sản phẩm cần đưa dữ liệu ecommerce vào Brevo, hãy dùng Tajo để kết nối sự kiện khách hàng, sự đồng thuận, sản phẩm, giỏ hàng và đơn hàng trước khi xây thêm thông điệp vòng đời.

Nếu bạn cần thiết lập SMTP, xem hướng dẫn SMTP đầy đủ và hướng dẫn máy chủ SMTP miễn phí.

Hướng dẫn liên quan

• Hướng dẫn dịch vụ email giao dịch
• Ví dụ email giao dịch
• Hướng dẫn SMTP đầy đủ
• SPF, DKIM và DMARC
• Hướng dẫn tự động hóa email
• Tích hợp Brevo Shopify