ส่งข้อมูลลงสมุดรายนามสำหรับหมายเลขโทรศัพท์

ส่งข้อมูลลงสมุดรายนามให้ผู้ให้บริการ

ส่งชื่อและที่อยู่สำหรับลงสมุดรายนามของหมายเลขโทรศัพท์ที่เข้าเกณฑ์และเป็นของคุณใน MultiTEL นี่คือการอัปเดตข้อมูลกับผู้ให้บริการที่มีค่าบริการ ไม่ใช่การค้นหาชื่อผู้โทร การเพิ่มรายการในสมุดที่อยู่ส่วนตัว หรือการอัปเดตทั่วไปในช่อง LIDB ของคลังหมายเลขบนพอร์ทัล

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

ข้อกำหนดเกี่ยวกับบัญชีและหมายเลข

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

คำขอ POST แบบฟอร์ม

กำหนด NUMBER ให้เป็นหมายเลขที่คุณเป็นเจ้าของ แทนที่ข้อมูลสมมติในตัวอย่างด้วยข้อมูลลงสมุดรายนามที่ได้รับอนุญาต เส้นทางนี้อ่านช่องข้อมูลแบบฟอร์มจาก POST โดยไม่แยกวิเคราะห์เนื้อหาคำขอแบบ application/json

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"

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

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

การเรียกเก็บเงินและพฤติกรรมเมื่อลองอีกครั้ง

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

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

คำตอบ

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

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

ข้อผิดพลาดของระบบเดิม

อ่านทั้งสถานะ HTTP และช่องข้อมูลใน JSON status.code/status.msg การยืนยันตัวตนและข้อจำกัด IP ต้นทางอาจทำให้ไม่ได้รับคำตอบที่ใช้งานได้เช่นกัน อย่าใช้ GET หรือพารามิเตอร์ในสตริงคำค้นเพื่อขออัปเดต เพียงเพราะตัวประมวลผลเดิมไม่มีกลไกตรวจสอบเมธอด HTTP อย่างชัดเจน

ตรวจสอบก่อนลองอีกครั้ง

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