Cập nhật thương hiệu nhắn tin

Chỉnh sửa thương hiệu nhắn tin hiện có

Cập nhật thương hiệu hiện có khi thông tin liên hệ hoặc địa chỉ của doanh nghiệp thay đổi. Giữ nguyên mã định danh thương hiệu; tạo thêm một đăng ký không phải là cách sửa thông tin của doanh nghiệp hiện có. Sử dụng tài khoản API đã được kích hoạt qua HTTPS từ địa chỉ IP nguồn được phép. Thương hiệu phải thuộc sở hữu của tài khoản đó.

Bắt đầu bằng việc đọc bản ghi hiện tại. Giữ bản sao cục bộ ở chế độ riêng tư vì bản sao chứa thông tin định danh và thông tin liên hệ của doanh nghiệp.

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

Giữ nguyên các trường hiện tại của thương hiệu

Chuẩn bị brand-update.json từ bản ghi hiện tại, chỉ chọn những trường thương hiệu có thể ghi. Giữ nguyên thông tin định danh doanh nghiệp và các giá trị bắt buộc khác khi áp dụng thay đổi dự kiến. Không gửi toàn bộ phản hồi GET: brandId, kết quả định danh/trạng thái, dấu thời gian và các trường khác chỉ có trong phản hồi không được đưa vào nội dung cập nhật.

Lược đồ cập nhật yêu cầu entityType, displayName, country, email và brandRelationship. Các quy tắc riêng cho từng loại chủ thể vẫn áp dụng. Đối với tổ chức, giữ nguyên tên công ty theo pháp lý, mã số thuế và quốc gia cấp mã, địa chỉ và ngành nghề theo trường hợp áp dụng. Đối với cá nhân kinh doanh, thay vào đó hãy giữ nguyên các trường tên cá nhân và thông tin liên hệ di động tương ứng. Sử dụng các giá trị thực tế hiện tại, không dùng giá trị giữ chỗ trong ví dụ đăng ký.

Sử dụng các danh mục nhắn tin hiện hành để tra mã. Lược đồ cập nhật không cung cấp mock làm cách thay đổi môi trường của thương hiệu. Hãy sử dụng quy trình riêng đã được rà soát để chuyển từ môi trường thử nghiệm sang môi trường vận hành thực tế, thay vì thay đổi cờ đó khi chỉnh sửa.

Gửi nội dung chỉnh sửa đã được rà soát

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @brand-update.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID"

Sử dụng một khóa cho lần cập nhật dự kiến này và giữ nguyên chính xác các byte của phần thân yêu cầu. Việc dùng lại khóa đó khi đã thay đổi phương thức, đường dẫn, chuỗi truy vấn hoặc phần thân sẽ gây xung đột; định dạng lại JSON cũng làm thay đổi dấu vân tay của yêu cầu. Yêu cầu trùng lặp với một yêu cầu đang được xử lý có thể trả về 409 kèm Retry-After. Yêu cầu đã hoàn tất có thể trả lại kết quả đã lưu, bao gồm cả lỗi. Giữ lại chi tiết yêu cầu khi đối soát trường hợp hết thời gian chờ, thay vì tự động tạo khóa mới.

Kiểm tra bản ghi đã lưu và trạng thái xác thực

Cập nhật thành công trả về HTTP 200 và trực tiếp một đối tượng JSON của thương hiệu, không có lớp bao v3 status/response kiểu cũ. Kiểm tra brandId của đối tượng, sau đó dùng GET để đọc lại chính thương hiệu đó và so sánh các trường dự định thay đổi. Tuyến cập nhật công khai không nhận lớp bao changes/version của cổng thông tin và cũng không cung cấp cơ chế kiểm tra đồng thời lạc quan của cổng. Hãy phối hợp giữa những người chỉnh sửa đồng thời; khóa chống xử lý lặp ngăn gửi trùng, chứ không ngăn thay đổi của người chỉnh sửa khác.

Cổng thông tin hiện tại đọc dữ liệu thương hiệu, giữ nguyên các trường có thể ghi, kiểm tra phiên bản biểu mẫu trước khi lưu rồi đọc lại kết quả. Cổng khóa các trường định danh pháp lý cốt lõi khi phát hiện chiến dịch đang hoạt động. Hệ thống đăng ký có thể áp đặt thêm các hạn chế, bao gồm hạn chế liên quan đến thẩm định bên ngoài, ngay cả khi biểu mẫu đã cho phép nhập một trường.

Việc lưu thông tin đã sửa không tự động yêu cầu xác minh danh tính mới và cũng không bảo đảm được phê duyệt. Xác minh lại là thao tác riêng có thể phát sinh phí; sử dụng cổng thông tin để xem trạng thái hiện tại và xác nhận rõ ràng mọi khoản phí được báo. Các cập nhật thương hiệu thông thường bằng PUT không kích hoạt khoản ghi nợ đăng ký riêng trong dịch vụ API hiện tại. Các khoản phí chiến dịch, nhắn tin và các khoản phí khác hiện có vẫn được tính riêng.

Xử lý lỗi mà không tạo đăng ký trùng lặp

Đọc trạng thái HTTP và chi tiết lỗi trong JSON. Với 400, sửa trường cụ thể hoặc tuân thủ hạn chế về định danh/quan hệ. Với 401, 403 hoặc 404, kiểm tra thông tin xác thực, IP nguồn được phép và quyền sở hữu của tài khoản. Với 429, tuân thủ Retry-After. Lỗi 500 hoặc 502 có thể xảy ra sau khi hệ thống đăng ký đã chấp nhận bản cập nhật; giữ lại mọi requestId nhận được và đọc bản ghi hiện có trước khi gửi lại.

Phản hồi cập nhật không rỗng nhưng thiếu dữ liệu có thể để lại bản chụp dữ liệu cục bộ không đầy đủ; phần thân phản hồi thành công rỗng có thể khiến các trường cũ trong bản chụp vẫn được giữ lại. Không suy ra rằng các trường đã được giữ nguyên chỉ dựa vào trạng thái thành công. Đọc lại toàn bộ dữ liệu thương hiệu và liên hệ bộ phận hỗ trợ để đối soát mọi sai lệch. Hướng dẫn này không cam kết rằng việc cập nhật hệ thống đăng ký, bộ nhớ đệm cục bộ và thanh toán diễn ra theo một thao tác nguyên tử.