อัปเดตแบรนด์สำหรับการส่งข้อความ

แก้ไขแบรนด์สำหรับการส่งข้อความที่มีอยู่

อัปเดตแบรนด์เดิมเมื่อข้อมูลติดต่อหรือที่อยู่ของธุรกิจเปลี่ยนแปลง คงรหัสแบรนด์เดิมไว้ การสร้างการลงทะเบียนอีกครั้งไม่ใช่วิธีแก้ไขข้อมูลของธุรกิจที่มีอยู่ ใช้บัญชี API ที่เปิดใช้งานแล้วผ่าน HTTPS จากที่อยู่ IP ต้นทางที่ได้รับอนุญาต แบรนด์ต้องเป็นของบัญชีนั้น

เริ่มต้นด้วยการอ่านระเบียนปัจจุบัน เก็บสำเนาในเครื่องเป็นความลับ เนื่องจากมีข้อมูลระบุตัวตนและข้อมูลติดต่อของธุรกิจ

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

คงค่าฟิลด์ปัจจุบันของแบรนด์ไว้

จัดเตรียม brand-update.json จากระเบียนปัจจุบัน โดยเลือกเฉพาะฟิลด์ของแบรนด์ที่เขียนได้ คงข้อมูลระบุตัวตนของธุรกิจและค่าอื่นที่จำเป็นไว้ขณะแก้ไขตามที่ต้องการ อย่าส่งการตอบกลับ GET ทั้งหมด: brandId ผลการตรวจสอบตัวตน/สถานะ เวลาประทับ และฟิลด์อื่นที่มีไว้เฉพาะในการตอบกลับ ไม่ควรอยู่ในข้อมูลอัปเดต

สคีมาการอัปเดตกำหนดให้ต้องมี entityType, displayName, country, email และ brandRelationship กฎเฉพาะของแต่ละประเภทผู้ประกอบการยังคงมีผล สำหรับองค์กร ให้คงชื่อบริษัทตามกฎหมาย เลขประจำตัวผู้เสียภาษีและประเทศที่ออกเลข ที่อยู่ และประเภทธุรกิจไว้ตามที่เกี่ยวข้อง สำหรับผู้ประกอบการเจ้าของคนเดียว ให้คงฟิลด์ชื่อบุคคลและข้อมูลติดต่อทางโทรศัพท์มือถือที่เกี่ยวข้องแทน ใช้ค่าจริงในปัจจุบัน ไม่ใช่ค่าตัวอย่างที่ใช้แทนข้อมูลในตัวอย่างการลงทะเบียน

กลุ่มฟิลด์สำหรับอัปเดตแบรนด์
ฟิลด์	วิธีใช้งาน
displayName, email, phone	ชื่อแบรนด์ที่จดจำได้และข้อมูลติดต่อที่ถูกต้อง ความยาวสูงสุด: 255, 100 และ 20 อักขระ ใช้รูปแบบหมายเลขโทรศัพท์สากลที่มีเครื่องหมาย + นำหน้ารหัสประเทศ
street, city, state, postalCode, country	ที่อยู่ธุรกิจจริงที่มีข้อมูลแต่ละส่วนสอดคล้องกัน ขีดจำกัด: 255, 100, 20, 10 และ 2 อักขระ ใช้รหัสรัฐของสหรัฐอเมริกาที่เป็นปัจจุบันในกรณีที่เกี่ยวข้อง
entityType, companyName, ein, einIssuingCountry	ข้อมูลระบุตัวตนตามกฎหมาย การเปลี่ยนแปลงเหล่านี้ถูกจำกัดเมื่อแคมเปญหรือการตรวจประเมินจากภายนอกอยู่ระหว่างรอดำเนินการหรือกำลังดำเนินอยู่ อย่าลบแคมเปญที่ใช้งานอยู่เพียงเพื่อหลีกเลี่ยงข้อจำกัดด้านข้อมูลระบุตัวตน
firstName, lastName, mobilePhone, businessContactEmail	ข้อมูลระบุตัวตนหรือข้อมูลติดต่อสำหรับการยืนยัน ตามความเหมาะสมกับประเภทผู้ประกอบการ ขีดจำกัด: 100, 100, 20 และ 255 อักขระ
brandRelationship, vertical	รหัสความสัมพันธ์และประเภทธุรกิจในปัจจุบัน การเปลี่ยนความสัมพันธ์ทำได้เพียงครั้งเดียวในสามเดือน แบบฟอร์มแก้ไขตามปกติของพอร์ทัลไม่รองรับการเปลี่ยนความสัมพันธ์
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	เว็บไซต์ ข้อมูลระบุตัวตนธุรกิจทางเลือก และรายละเอียดบริษัทมหาชน ตามที่เกี่ยวข้อง คงค่าที่จำเป็นต่อการตรวจสอบความถูกต้องของผู้ประกอบการไว้
referenceId, ipAddress	ข้อมูลเมตาที่รองรับสำหรับการอ้างอิงธุรกิจและ IP ต้นทาง ทั้งสองค่าไม่ได้กำหนดความเป็นเจ้าของของบัญชี และไม่ได้ทำหน้าที่เป็นคีย์ป้องกันการประมวลผลซ้ำของคำขอ

ใช้ รายการอ้างอิงสำหรับการส่งข้อความ ฉบับปัจจุบันเพื่อดูรหัส สคีมาการอัปเดตไม่ได้เปิดให้ใช้ mock เป็นวิธีเปลี่ยนสภาพแวดล้อมของแบรนด์ ให้ใช้ขั้นตอนแยกต่างหากสำหรับย้ายจากสภาพแวดล้อมทดสอบไปยังสภาพแวดล้อมใช้งานจริงที่ผ่านการตรวจทานแล้ว แทนการเปลี่ยนแฟล็กนั้นระหว่างแก้ไข

ส่งข้อมูลแก้ไขที่ผ่านการตรวจทานแล้ว

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"

ใช้คีย์เดียวสำหรับการอัปเดตที่ตั้งใจทำครั้งนี้ และเก็บไบต์ของเนื้อหาคำขอให้ตรงตามต้นฉบับทุกประการ การนำคีย์กลับมาใช้เมื่อเปลี่ยนเมธอด พาธ คิวรี หรือเนื้อหาแล้วจะเกิดข้อขัดแย้ง การจัดรูปแบบ JSON ใหม่ก็ทำให้ลายนิ้วมือของคำขอเปลี่ยนไปเช่นกัน คำขอซ้ำกับคำขอที่กำลังประมวลผลอาจส่งกลับ 409 พร้อม Retry-After คำขอที่เสร็จสิ้นแล้วอาจส่งผลลัพธ์ที่บันทึกไว้กลับมาอีกครั้ง รวมถึงผลลัพธ์ที่เป็นข้อผิดพลาดด้วย เก็บรายละเอียดคำขอไว้เมื่อตรวจสอบผลหลังหมดเวลารอ แทนการสร้างคีย์ใหม่โดยอัตโนมัติ

ตรวจสอบระเบียนที่บันทึกและสถานะการตรวจสอบความถูกต้อง

การอัปเดตที่สำเร็จจะส่งกลับ HTTP 200 และออบเจ็กต์ JSON ของแบรนด์โดยตรง โดยไม่มีโครงสร้างครอบ v3 status/response แบบเดิม ตรวจสอบ brandId จากนั้นใช้ GET อ่านแบรนด์เดิมอีกครั้งและเปรียบเทียบฟิลด์ที่ตั้งใจแก้ไข เส้นทางอัปเดตสาธารณะไม่รับโครงสร้างครอบ changes/version ของพอร์ทัล และไม่มีการตรวจสอบการแก้ไขพร้อมกันแบบออปทิมิสติกเช่นเดียวกับพอร์ทัล ควรประสานงานระหว่างผู้ที่แก้ไขพร้อมกัน คีย์ป้องกันการประมวลผลซ้ำป้องกันการส่งซ้ำ แต่ไม่ได้ป้องกันการเปลี่ยนแปลงจากผู้แก้ไขคนอื่น

พอร์ทัลปัจจุบันอ่านข้อมูลแบรนด์ คงค่าฟิลด์ที่เขียนได้ ตรวจสอบเวอร์ชันของแบบฟอร์มก่อนบันทึก แล้วอ่านผลลัพธ์อีกครั้ง พอร์ทัลจะล็อกฟิลด์หลักที่ใช้ระบุตัวตนตามกฎหมายเมื่อพบแคมเปญที่ใช้งานอยู่ ระบบทะเบียนอาจกำหนดข้อจำกัดเพิ่มเติม รวมถึงข้อจำกัดเกี่ยวกับการตรวจประเมินจากภายนอก แม้แบบฟอร์มจะเปิดให้แก้ไขฟิลด์นั้นก็ตาม

การบันทึกข้อมูลที่แก้ไขแล้วไม่ได้ร้องขอการยืนยันตัวตนใหม่โดยอัตโนมัติ และไม่ได้รับประกันว่าจะได้รับอนุมัติ การยืนยันซ้ำเป็นการดำเนินการแยกต่างหากที่อาจมีค่าธรรมเนียม ใช้พอร์ทัลเพื่อตรวจสอบสถานะปัจจุบันและยืนยันค่าธรรมเนียมที่เสนออย่างชัดเจน การอัปเดตแบรนด์ตามปกติด้วย PUT ไม่ทำให้เกิดการหักเงินค่าลงทะเบียนแยกต่างหากในบริการ API ปัจจุบัน ค่าใช้จ่ายแคมเปญ การส่งข้อความ และค่าใช้จ่ายอื่นที่มีอยู่ยังคงแยกจากกัน

แก้ไขข้อผิดพลาดโดยไม่ลงทะเบียนซ้ำ

อ่านสถานะ HTTP และรายละเอียดข้อผิดพลาดใน JSON สำหรับ 400 ให้แก้ไขฟิลด์ที่ระบุหรือปฏิบัติตามข้อจำกัดด้านข้อมูลระบุตัวตน/ความสัมพันธ์ สำหรับ 401, 403 หรือ 404 ให้ตรวจสอบข้อมูลรับรอง IP ต้นทางที่ได้รับอนุญาต และความเป็นเจ้าของของบัญชี สำหรับ 429 ให้ปฏิบัติตาม Retry-After ข้อผิดพลาด 500 หรือ 502 อาจเกิดขึ้นหลังจากระบบทะเบียนยอมรับการอัปเดตแล้ว เก็บ requestId ที่ได้รับไว้ และอ่านระเบียนเดิมก่อนส่งอีกครั้ง

การตอบกลับการอัปเดตที่ไม่ว่างแต่มีข้อมูลไม่ครบอาจทำให้สำเนาข้อมูล ณ ขณะนั้นในเครื่องไม่ครบถ้วน ส่วนการตอบกลับที่สำเร็จแต่มีเนื้อหาว่างอาจทำให้ยังคงค่าฟิลด์จากสำเนาเดิมไว้ อย่าสรุปว่าค่าฟิลด์ถูกคงไว้จากสถานะสำเร็จเพียงอย่างเดียว อ่านข้อมูลแบรนด์ทั้งหมดกลับมาอีกครั้ง และติดต่อฝ่ายสนับสนุนเพื่อตรวจสอบและแก้ไขข้อมูลที่ไม่ตรงกัน คู่มือนี้ไม่ได้รับประกันว่าการอัปเดตระบบทะเบียน แคชในเครื่อง และการเรียกเก็บเงินจะเกิดขึ้นแบบอะตอมมิกเป็นหน่วยเดียวกัน