Đọc các yêu cầu chiến dịch của một thương hiệu

Giữ thương hiệu và trường hợp sử dụng đi cùng nhau

Sử dụng ID thương hiệu trên tài khoản của bạn và một giá trị trường hợp sử dụng được trả về từ danh sách đủ điều kiện của chính thương hiệu đó. Quy trình khách hàng kiểm tra quyền sở hữu trước khi gửi yêu cầu đến nhà cung cấp. Xác nhận rằng trường usecase của đối tượng được trả về khớp với giá trị đã chọn. Một lần tra cứu cho một thương hiệu hoặc trường hợp sử dụng không xác lập yêu cầu cho thương hiệu hoặc trường hợp sử dụng khác.

Đọc các yêu cầu hiện tại

Các yêu cầu được biểu mẫu chiến dịch hiện tại sử dụng
Trường	Cách cổng thông tin sử dụng
minSubUsecases / maxSubUsecases	Số lượng tối thiểu và tối đa của các trường hợp sử dụng phụ cho lựa chọn này. Chọn giá trị từ danh mục trường hợp sử dụng phụ hợp lệ thay vì nhập văn bản tự do.
mnoMetadata	Các yêu cầu riêng theo nhà mạng, được khóa theo ID nhà mạng. Sử dụng các ID có trong phản hồi hiện tại để chọn nhà mạng.
mnoSupport / qualify	Hỗ trợ và điều kiện đủ của nhà mạng. Cổng thông tin loại trừ các nhà mạng được đánh dấu rõ ràng là false ở một trong hai trường và yêu cầu ít nhất một nhà mạng được chọn đủ điều kiện.
minMsgSamples	Số lượng mẫu bắt buộc cho một nhà mạng. Cổng thông tin yêu cầu ít nhất một mẫu không rỗng và đáp ứng mức tối thiểu cao nhất trong số các nhà mạng được chọn đủ điều kiện.
reqSubscriberOptin / reqSubscriberOptout / reqSubscriberHelp	Các khai báo thuê bao bắt buộc. Khi được yêu cầu, khai báo tương ứng phải là true. Các khai báo được bật cũng cần các trường từ khóa và thông điệp phản hồi của chúng.
noEmbeddedLink / noEmbeddedPhone	Các hạn chế về liên kết hoặc số điện thoại nhúng. Cổng thông tin từ chối một tính năng đã khai báo nếu một nhà mạng được chọn đủ điều kiện cấm tính năng đó.

Áp dụng đồng thời yêu cầu của các nhà mạng đã chọn

Yêu cầu của các nhà mạng có thể khác nhau. Khi không cung cấp danh sách nhà mạng rõ ràng, cổng thông tin xem xét toàn bộ siêu dữ liệu nhà mạng trong phản hồi; một danh sách không rỗng giới hạn các kiểm tra ở những ID đã chọn đó. Không chỉ dùng số lượng mẫu hoặc khai báo của nhà mạng đầu tiên. Chọn nhà mạng từ phản hồi, kiểm tra hỗ trợ và điều kiện đủ, đáp ứng mức tối thiểu mẫu cao nhất áp dụng, và thỏa mãn các khai báo bắt buộc về đăng ký nhận (opt-in), hủy nhận (opt-out) và trợ giúp trên toàn bộ lựa chọn đó. Cổng thông tin từ chối các ID nhà mạng đã chọn không có trong phản hồi hiện tại và từ chối lựa chọn không có nhà mạng đủ điều kiện nào.

Các yêu cầu mô tả những gì phải cung cấp; chúng không chứng minh rằng quy trình lấy sự đồng ý của khách hàng hoặc nội dung chiến dịch đáp ứng các yêu cầu đó. Thu thập các mẫu và khai báo trung thực, mang tính đại diện. Không tự động bật các khai báo chỉ để biểu mẫu được thông qua.

Chuẩn bị mẫu tin nhắn và phản hồi cho thuê bao

Biểu mẫu chiến dịch hiện tại sử dụng sample1 đến sample5 cho các mẫu tin nhắn. Nếu không thể đáp ứng các yêu cầu trong biểu mẫu hiện có, hãy dừng lại và giải quyết lựa chọn với bộ phận hỗ trợ. Đối với một khai báo thuê bao được bật, hãy cung cấp các từ khóa và văn bản phản hồi tương ứng: optinKeywords/optinMessage, optoutKeywords/optoutMessage, và helpKeywords/helpMessage. Giữ các mẫu nhất quán với trường hợp sử dụng đã chọn và nội dung nhắn tin thực tế của khách hàng.

Rà soát trước mọi yêu cầu đăng ký

Làm mới các yêu cầu khi thương hiệu, trường hợp sử dụng hoặc lựa chọn nhà mạng thay đổi. Cổng thông tin xác thực lại trường hợp sử dụng đã chọn, số lượng trường hợp sử dụng phụ, điều kiện đủ của nhà mạng, các mẫu và các khai báo trước khi tạo. Xem xét giá tài khoản và điều khoản đăng ký riêng. GET này không đăng ký hay phê duyệt chiến dịch, không chia sẻ chiến dịch với nhà mạng nhắn tin và không gán số điện thoại. Tạo và cấp phát là các thao tác riêng biệt.

Xử lý tra cứu yêu cầu thất bại

Nếu yêu cầu thất bại, trả về JSON không mong đợi hoặc không khớp với trường hợp sử dụng đã chọn, hãy giữ biểu mẫu ở trạng thái chưa hoàn tất và để khách hàng thử lại sau khi lỗi được khắc phục. Không thay thế các yêu cầu không khả dụng bằng một đối tượng rỗng và không giả định rằng dữ liệu bị thiếu có nghĩa là không có yêu cầu. Tuân thủ Retry-After và sử dụng cơ chế chờ lùi (backoff) đối với giới hạn tốc độ và các lỗi về tính khả dụng.

Yêu cầu

Sử dụng một tài khoản API đã được bật qua HTTPS từ một địa chỉ IP nguồn được phép. Tuyến hiện tại hỗ trợ chính sách xác thực tài khoản, bao gồm xác thực Basic và các tài khoản API bearer đã được bật. Không sử dụng thông tin xác thực của nhà cung cấp.

GET với ID thương hiệu và giá trị trường hợp sử dụng đã chọn trong đường dẫn URL. Không yêu cầu nội dung yêu cầu (request body).

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID/usecase/$USECASE"

Tham số đường dẫn
Tên	Kiểu	Bắt buộc	Mô tả
`brand_id`	string	Có	ID thương hiệu trong sổ đăng ký được liên kết với tài khoản MultiTEL đã xác thực của bạn. Sử dụng ID thương hiệu, không phải ID hàng trong cơ sở dữ liệu cục bộ, ID chiến dịch hay mã số thuế doanh nghiệp. Mã hóa nó thành một phân đoạn đường dẫn URL duy nhất.
`usecase`	string	Có	Giá trị usecase dạng máy đọc được, được chọn từ danh sách đủ điều kiện của chính thương hiệu này. Giữ nguyên chữ hoa/chữ thường; không gửi nhãn hiển thị đã dịch. Mã hóa nó thành một phân đoạn đường dẫn URL duy nhất.

Phản hồi

Tuyến TCR hiện tại trả về trực tiếp nội dung JSON của sổ đăng ký và giữ nguyên trạng thái HTTP của nó. Nó không thêm lớp bao status/response kiểu v3 cũ. Ví dụ hư cấu rút gọn không phải là kết quả đủ điều kiện thực tế. Kiểm tra trạng thái HTTP và cấu trúc JSON mong đợi trước khi sử dụng. Cổng thông tin mong đợi một đối tượng có usecase khớp với trường hợp sử dụng đã chọn. Các yêu cầu của nhà mạng nằm dưới mnoMetadata, được khóa theo ID nhà mạng. ID nhà mạng và các yêu cầu trong ví dụ là hư cấu. Các trường khác của nhà cung cấp có thể được trả về.

Cấu trúc phản hồi minh họa; không phải dữ liệu tài khoản thực tế hay báo giá hiện hành.

{
  "usecase": "2FA",
  "minSubUsecases": 0,
  "maxSubUsecases": 0,
  "mnoMetadata": {
    "12345": {
      "mnoSupport": true,
      "qualify": true,
      "minMsgSamples": 1,
      "reqSubscriberOptin": true,
      "reqSubscriberOptout": true,
      "reqSubscriberHelp": true,
      "noEmbeddedLink": false,
      "noEmbeddedPhone": false
    }
  }
}

Lỗi

401: Xác thực tài khoản thất bại. Kiểm tra thông tin xác thực API, trạng thái bật và các hạn chế IP nguồn áp dụng.
404: Thương hiệu không được liên kết với tài khoản đã xác thực, hoặc nhà cung cấp không tìm thấy thương hiệu hoặc lựa chọn được yêu cầu. Việc từ chối quyền sở hữu cục bộ được trả về trước khi gửi yêu cầu đến nhà cung cấp.
Các lỗi sổ đăng ký khác: Trạng thái HTTP và nội dung từ phía trên (upstream) được giữ nguyên. Một trường hợp sử dụng không hợp lệ hoặc không khả dụng không phải là một tập yêu cầu rỗng thành công.
429: Đã đạt giới hạn yêu cầu của tài khoản hoặc của nhà cung cấp dùng chung. Tuân thủ Retry-After.
502/503: Lỗi về tính khả dụng của tầng truyền tải, nhà cung cấp hoặc bộ giới hạn tốc độ. Giữ nguyên biểu mẫu và thử lại với cơ chế chờ lùi.

Tính khả dụng và tác dụng phụ

GET đã rà soát kiểm tra quyền sở hữu thương hiệu hiện có, liên hệ với sổ đăng ký và ghi các bản ghi kiểm toán yêu cầu. Nó không tạo thương hiệu hay chiến dịch và không tính phí đăng ký.
Siêu dữ liệu phí của nhà cung cấp không phải là báo giá bán lẻ cho khách hàng MultiTEL. Cổng thông tin xem xét giá tài khoản riêng trước một yêu cầu đăng ký sau này.
Điều kiện đủ và các yêu cầu có thể thay đổi. Làm mới chúng cho thương hiệu và trường hợp sử dụng đã chọn trước khi gửi. Một lần tra cứu thành công không phải là phê duyệt chiến dịch, gán số hay cho phép bắt đầu nhắn tin.