Checkify
เอกสารสำหรับนักพัฒนา

ยืนยันบน backend ของคุณ

หลัง embed บนเบราว์เซอร์เสร็จ เซิร์ฟเวอร์ของคุณต้องยืนยันผลลัพธ์ด้วย site API key ก่อนอนุญาตการสมัคร ชำระเงิน หรือการดำเนินการที่ปกป้อง

การตรวจสอบเซิร์ฟเวอร์ใช้เวลา 5 นาที

  1. เพิ่มโค้ดฝังเบราว์เซอร์ Checkify ลงในหน้าเว็บของคุณ
  2. โค้ดฝังตัวนี้จะเริ่มต้นเซสชัน Checkify และเขียนข้อมูลอ้างอิงการตรวจสอบลงในแบบฟอร์มของคุณ
  3. ระบบแบ็กเอนด์ของคุณจะอ่านค่าจากฟิลด์ที่ซ่อนอยู่
  4. ระบบแบ็กเอนด์ของคุณจะส่งค่าดังกล่าวไปยัง POST /v1/qr/results/verify โดยใช้ request_id เป็นพารามิเตอร์
  5. หากคำร้องขอได้รับการอนุมัติแล้ว ให้ดำเนินการตามคำสั่งศาลที่ได้รับการคุ้มครอง
  6. อย่าเชื่อถือสถานะฝั่ง frontend เพียงอย่างเดียว

ช่องข้อมูลที่ซ่อนอยู่ อาจมีชื่อว่า checkify_token แต่ค่าของมันคือ request_id ของ Checkify

กระบวนการทำงานตั้งแต่ต้นจนจบ

1. สร้าง site API key

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

ใช้ frontend SDK ใช่หรือไม่

คุณไม่จำเป็นต้องเรียกใช้คำสั่ง GET /v1/qr/pass/{PASS_ID}/start ด้วยตนเอง ส่วนประกอบ Checkify JavaScript จะเริ่มต้นเซสชัน รับ request_id และเขียนลงในฟอร์มของคุณโดยอัตโนมัติ

ระบบแบ็กเอนด์ของคุณจำเป็นต้องมีเพียงแค่:

2. รับ request_id บนเซิร์ฟเวอร์ของคุณ

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

การส่งต่อแอปบนมือถืออาจส่งค่า checkify_request_id กลับมาใน URL ของหน้าเว็บ SDK จะอ่านค่านี้เมื่อโหลดหน้าเว็บ และเซิร์ฟเวอร์ของคุณจะยังคงตรวจสอบค่า request_id เดิมอยู่

ส่งฟอร์ม POST จากฝั่ง frontend ของคุณ

{
  "email": "user@example.com",
  "checkify_token": "56a57761-ff5b-42f0-9c97-6c13e223e017"
}

ตรวจสอบคำขอจากระบบแบ็กเอนด์ของคุณ

{
  "request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
  "required_claims": ["human_verified"],
  "required_fields": [],
  "consume": true
}

การผสานรวมส่วนหน้าด้วยตนเองเท่านั้น

3. การทดสอบด้วยตนเองโดยใช้ cURL

โดยปกติแล้วนักพัฒนาแบ็กเอนด์จะไม่เรียกใช้ /start ให้ใช้ส่วนนี้เฉพาะเมื่อสร้างฟรอนต์เอนด์แบบกำหนดเองหรือทดสอบโดยไม่ใช้การฝัง ใส่เครื่องหมายอัญประกาศใน URL ใน zsh/bash เพื่อไม่ให้ ? ถูกมองว่าเป็นรูปแบบ glob

ส่วนหัว Origin จำเป็นสำหรับ /start

คำสั่ง Pass start ใช้ได้เฉพาะกับโดเมนเว็บไซต์ที่ลงทะเบียนไว้เท่านั้น เบราว์เซอร์จะส่ง Origin โดยอัตโนมัติ แต่ cURL ไม่ได้ทำเช่นนั้น คุณต้องส่ง Origin (หรือ X-Checkify-Site-Url) พร้อมกับชื่อโฮสต์ที่อยู่ในรายการภายใต้ Sites → allowed domains ชื่อโฮสต์ต้องตรงกันทุกประการ — checkify.me และ www.checkify.me นั้นแตกต่างกัน

ปัญหาการทดสอบที่พบบ่อยที่สุด

หากคำสั่ง /start ส่งคืน HTTP 403 รหัสผ่านของคุณอาจยังคงใช้งานได้ สาเหตุทั่วไปคือโดเมนที่ร้องขอไม่อยู่ในรายการโดเมนที่อนุญาต หรือ www.example.com ถูกจดทะเบียนแต่ใช้ example.com แทน (หรือในทางกลับกัน)

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

# Step A — start a session (replace PASS_ID and YOUR_REGISTERED_DOMAIN)
curl -sS \
  -H "Accept: application/json" \
  -H "Origin: https://YOUR_REGISTERED_DOMAIN" \
  "https://checkify.me/v1/qr/pass/chk_live_YOUR_PASS_ID/start?request_type=human"

# Response includes request_id and qr_url — open qr_url and complete verification

# Step B — verify on your server (after the user completes verification)
curl -sS -X POST "https://checkify.me/v1/qr/results/verify" \
  -H "Authorization: Bearer $CHECKIFY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "PASTE_request_id_FROM_STEP_A",
    "required_claims": ["human_verified"],
    "consume": true
  }'

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

การเรียกร้องที่จำเป็นตามกรณีการใช้งาน

ตั้งค่า required_claims ให้ตรงกับหลักฐานที่การดำเนินการที่ได้รับการปกป้องของคุณต้องการ ชื่อการอ้างสิทธิ์ต้องตรงกับที่ Checkify อนุมัติสำหรับเซสชันการตรวจสอบนั้น การตรวจสอบอายุใช้ age_over_{N} (ตัวอย่างเช่น age_over_18) รองรับเกณฑ์แบบไดนามิกตั้งแต่ 10 ถึง 110 เมื่อการฝังร้องขอประเภทคำขอที่ตรงกัน

กรณีศึกษา ข้อเสนอแนะเกี่ยวกับข้อเรียกร้องที่จำเป็น หมายเหตุ
บอท / CAPTCHA ทดแทน ["human_verified"] ยืนยันว่าผู้ใช้จริงได้ดำเนินการตามขั้นตอน Checkify เสร็จสมบูรณ์แล้ว
เนื้อหาสำหรับผู้ที่มีอายุ 13 ปีขึ้นไป หรือผลิตภัณฑ์ที่มุ่งเน้นกลุ่มเยาวชน ["age_over_13"] ใช้เมื่อโปรแกรม Pass ของคุณกำหนดให้ต้องมีอายุมากกว่า 13 ปี
เนื้อหาสำหรับผู้ที่มีอายุ 16 ปีขึ้นไป หรือข้อกำหนดด้านอายุในแต่ละภูมิภาค ["age_over_16"] ใช้เมื่อโปรแกรม Pass ของคุณกำหนดให้ต้องมีอายุมากกว่า 16 ปี
การชำระเงินสำหรับบุหรี่ไฟฟ้า เครื่องดื่มแอลกอฮอล์ หรือสินค้าสำหรับผู้ที่มีอายุ 18 ปีขึ้นไป ["age_over_18"] กำหนดช่วงอายุที่เหมาะสมให้ตรงกับผลิตภัณฑ์และกลุ่มเป้าหมายของคุณ
สินค้าที่จำกัดสำหรับผู้ที่มีอายุ 21 ปีขึ้นไป (ในกรณีที่เกี่ยวข้อง) ["age_over_21"] ใช้เมื่อโปรแกรม Pass ของคุณกำหนดให้ต้องมีอายุมากกว่า 21 ปี
นโยบายการค้าปลีกที่เข้มงวดกว่า เช่น Challenge 25 ["age_over_25"] ใช้เมื่อโปรแกรม Pass ของคุณกำหนดให้ต้องมีอายุมากกว่า 25 ปี
เกณฑ์อายุที่กำหนดเอง ["age_over_N"] ใช้ age_over_N โดยที่ N มีค่าอยู่ระหว่าง 10–110 ซึ่งสอดคล้องกับประเภทคำขอฝังข้อมูลของคุณ

ประเภทคำขอฝังตัว → การอ้างสิทธิ์ของเซิร์ฟเวอร์

ประเภทคำขอของเบราว์เซอร์ต้องตรงกับข้อมูลที่คุณตรวจสอบฝั่งเซิร์ฟเวอร์

ประเภทคำขอฝังตัวการเรียกร้องที่จำเป็น
human["human_verified"]
age_over_13["age_over_13"]
age_over_16["age_over_16"]
age_over_18["age_over_18"]
age_over_21["age_over_21"]
age_over_25["age_over_25"]
age_over_N["age_over_N"] (N = 10–110)

ช่องข้อมูลที่จำเป็น (ไม่บังคับ)

นอกจาก required_claims คุณอาจกำหนดฟิลด์อัตลักษณ์ที่อนุมัติแล้ว (เช่น ประเทศหรือช่วงอายุ) เมื่อการเชื่อมต่อเก็บข้อมูลนั้นแล้ว ส่งชื่อฟิลด์ใน required_fields — หากขาดในผลที่อนุมัติ verify จะคืน missing_required_fields พร้อม missing_fields ใน error.details

4. เรียกใช้ฟังก์ชัน verify บนเซิร์ฟเวอร์ของคุณ

เรียกใช้ POST /v1/qr/results/verify ด้วยคีย์ API ของเว็บไซต์ของคุณก่อนที่จะอนุญาตการเข้าถึง ให้ถือว่าข้อมูลอ้างอิงของเบราว์เซอร์ (request_id หรือโทเค็นการสำรวจแบบเดิม) ไม่น่าเชื่อถือจนกว่า Checkify จะยืนยันผลลัพธ์

POST https://checkify.me/v1/qr/results/verify
Authorization: Bearer YOUR_SITE_API_KEY
Content-Type: application/json

{
  "request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
  "required_claims": ["human_verified"],
  "consume": true
}

คุณสามารถส่งได้เช่นกัน token แทนที่จะ request_id. คีย์ API มีขอบเขตเฉพาะสำหรับไซต์ Checkify ของคุณ — คุณไม่ต้องส่ง site_id ในเนื้อหาคำขอ

ตัวอย่างการนำไปใช้

# checkify_token from your form POST is sent as request_id
curl -sS -X POST "https://checkify.me/v1/qr/results/verify" \
  -H "Authorization: Bearer $CHECKIFY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
    "required_claims": ["human_verified"],
    "consume": true
  }'

ควรใช้ consume เมื่อใด

ใช้ consume: true สำหรับการดำเนินการที่ได้รับการป้องกันขั้นสุดท้าย — การชำระเงิน, การสมัครสมาชิก, การรีเซ็ตรหัสผ่าน, การซื้อที่จำกัดอายุ, การเข้าถึงเนื้อหาที่ได้รับการป้องกัน

ใช้ consume: false เฉพาะสำหรับ — การทดสอบ การแก้ไขข้อผิดพลาด หรือการตรวจสอบที่ไม่ใช่ขั้นสุดท้าย ซึ่งต้องตรวจสอบผลลัพธ์อีกครั้งในภายหลัง

สำหรับการดำเนินการที่มีการควบคุมหรือมีความเสี่ยงสูง ควรเลือก consume: true เพื่อป้องกันไม่ให้ผลการตรวจสอบเดียวกันถูกนำไปใช้ซ้ำสำหรับการตัดสินใจที่ได้รับการปกป้องหลายรายการ

ปิดให้บริการสำหรับการดำเนินการที่อยู่ภายใต้การกำกับดูแล

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

ใช้ค่าหมดเวลา HTTP สั้นๆ (เช่น 10 วินาที) ลองเชื่อมต่อใหม่หนึ่งหรือสองครั้งสำหรับข้อผิดพลาด 5xx ชั่วคราวหรือข้อผิดพลาดเครือข่าย จากนั้นปฏิเสธการเข้าถึง บันทึกเหตุการณ์ที่ฝั่งเซิร์ฟเวอร์และแสดงข้อความที่ปลอดภัยสำหรับผู้ใช้ อย่าเปิดเผยรายละเอียดข้อผิดพลาด Checkify ภายในให้กับลูกค้า

try {
  const verdict = await verifyCheckifyResult(requestId);

  if (!verdict.allow) {
    return res.status(403).json({ error: "Verification required" });
  }

  // Continue protected action
} catch (err) {
  console.error("Checkify verification unavailable", err);

  return res.status(403).json({
    error: "Verification is temporarily unavailable. Please try again.",
  });
}

เซิร์ฟเวอร์ SDK และเครื่องมือ

The Checkify monorepo includes @checkify/server (Node.js) and checkify-server (Python) packages for server-side verify calls. There is no published OpenAPI spec or Postman collection yet — use the examples on this page and POST /v1/qr/results/verify directly.

@checkify/server v1.0.0 ได้ถูกเผยแพร่บน npm แล้ว แพ็กเกจ checkify-server สำหรับ Python นั้นรวมอยู่ใน monorepo Checkify SDK

ระยะเวลาหมดอายุของผลลัพธ์

การตรวจสอบที่เสร็จสมบูรณ์จะหมดอายุหลังจาก QR_RESULT_MAX_AGE_SECONDS (ค่าเริ่มต้น 900 วินาที / 15 นาที) หลังจากหมดอายุ การตรวจสอบจะส่งคืนค่า result_expired — โปรดขอให้ผู้ใช้ตรวจสอบอีกครั้ง

จุดเชื่อมต่อสำหรับตรวจสอบสถานะ (ส่วนหน้าแบบกำหนดเอง)

JavaScript SDK จัดการสถานะเซสชันสำหรับฝังมาตรฐาน ใช้สิ่งเหล่านี้เฉพาะเมื่อคุณสร้างส่วนหน้าแบบกำหนดเองที่เรียกใช้ GET /v1/qr/pass/{pass_id}/start ด้วยตนเอง

การจัดการ response

เมื่อสำเร็จ Checkify จะส่งคืน HTTP 200 พร้อม success: true และ status: completed อนุญาตการเข้าถึงเฉพาะเมื่อมีคุณสมบัติที่จำเป็นครบถ้วน (เช่น human_verified: true)

{
  "success": true,
  "status": "completed",
  "message": "Verification result confirmed",
  "request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
  "site_id": "YOUR_SITE_ID",
  "business_id": "YOUR_BUSINESS_ID",
  "approved_claims": {
    "human_verified": true
  },
  "approved_fields": [],
  "signed_result": {
    "payload": { "...": "..." },
    "signature": "...",
    "signature_algorithm": "EdDSA",
    "key_id": "checkify:default"
  }
}

ผลลงนาม

ออบเจ็กต์ signed_result ให้แบ็กเอนด์เก็บบันทึกตรวจสอบที่ป้องกันการปลอมแปลงว่า Checkify อนุมัติ claim ที่ต้องการตอนยืนยัน ระบบส่วนใหญ่ต้องการเพียง approved_claims ธุรกิจที่มีการกำกับดูแลหรือความเสี่ยงสูงอาจเก็บ signed_result ด้วย proof_metadata ที่ซ้อนกันอาจมีหลักฐานเชิงคริปโตหรือเชิงปฏิบัติการ (เช่น เมทาดาทา assurance ประเภทหลักฐาน หรือแฮชความยินยอม) — ไม่ใช่เอกสารประจำตัวหรือวันเกิดดิบ อย่าถือว่าฟิลด์ assurance ที่ซ้อนเป็นใบรับรองหรือการรับประกันความเชื่อถือ ตรวจสอบ certification_status และนโยบายของคุณ อย่าเก็บข้อมูลส่วนบุคคลเกินจำเป็น

หากลูกค้ายังใช้งานแอปไม่เสร็จสิ้น Checkify จะส่งคืน HTTP 200 พร้อม success: false และ status: pending ปฏิเสธการดำเนินการที่ได้รับการป้องกัน และขอให้ผู้ใช้ทำการยืนยันตัวตนให้เสร็จสิ้น

{
  "success": false,
  "status": "pending",
  "message": "Verification is not completed yet",
  "request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
  "approved_claims": {},
  "signed_result": null
}
สนามความหมาย
successtrue เมื่อการยืนยันเสร็จและตรงตามข้อกำหนด
statuscompleted หรือ pending
approved_claimsClaims ที่ Checkify อนุมัติ เช่น human_verified: true
signed_resultSigned payload ไม่บังคับสำหรับ audit trail

เพย์โหลดข้อผิดพลาด JSON

เมื่อการตรวจสอบไม่สามารถดำเนินการต่อได้ Checkify จะส่งคืน HTTP 4xx/5xx พร้อมด้วยเนื้อหา JSON ที่มีโครงสร้าง ตรวจสอบ error.code และบันทึก error.details ฝั่งเซิร์ฟเวอร์ ส่งข้อความทั่วไปกลับไปยังผู้ใช้ปลายทาง

{
  "success": false,
  "error": {
    "code": "verification_failed",
    "message": "The verification did not include all required claims.",
    "details": {
      "missing_claims": ["age_over_18"]
    }
  }
}
รหัส ทศนิยม ความหมาย การดำเนินการที่แนะนำ
missing_authorization401ไม่มีการส่งส่วนหัวการอนุญาต (Authorization header)ส่งคำอนุญาต: Bearer YOUR_SITE_API_KEY จากโค้ดฝั่งเซิร์ฟเวอร์เท่านั้น
invalid_token401โทเค็น Bearer หายไป รูปแบบไม่ถูกต้อง หรือไม่ใช่คีย์ API ของไซต์ที่ถูกต้องตรวจสอบรหัสสำคัญในแดชบอร์ดธุรกิจของคุณและบันทึกไว้ในตัวแปรสภาพแวดล้อม
expired_token401คีย์เว็บไซต์ API ถูกยกเลิกแล้วสร้างคีย์ไซต์ใหม่ชื่อ API แล้วหมุนเวียนคีย์นั้นบนเซิร์ฟเวอร์ของคุณ
missing_required_field400 / 422request_id หรือ token หายไปจาก body ของ JSONส่งค่า request_id จากช่องข้อมูลที่ซ่อนอยู่ในฟอร์มของคุณ หรือโทเค็นแบบสำรวจหากการเชื่อมต่อของคุณยังคงใช้โทเค็นอยู่
invalid_request_id400ไม่สามารถแยกวิเคราะห์ข้อมูลอ้างอิงได้ หรือข้อมูลอ้างอิงว่างเปล่าหลังจากทำการปรับให้เป็นมาตรฐานแล้วตรวจสอบให้แน่ใจว่าฝั่ง frontend ของคุณส่ง request_id Checkify โดยไม่เปลี่ยนแปลง
result_not_found404ไม่มีคำขอตรวจสอบความถูกต้องสำหรับข้อมูลอ้างอิงนั้นปฏิเสธการดำเนินการ ผู้ใช้อาจแก้ไขข้อมูลในช่องที่ซ่อนไว้ หรือส่งข้อมูลจากเซสชันเก่า
result_expired410การตรวจสอบเสร็จสิ้นไปนานเกินไปแล้ว จึงไม่น่าเชื่อถือสำหรับการดำเนินการนี้ขอให้ผู้ใช้สแกนอีกครั้งและเรียกใช้ฟังก์ชันตรวจสอบโดยใช้ request_id ใหม่
verification_failed403 / 409ไซต์/ธุรกิจไม่ตรงกัน ผลลัพธ์ถูกใช้แล้ว (HTTP 409) หรือการยืนยันล้มเหลวทั่วไปปฏิเสธการเข้าถึง ตรวจ error.details สำหรับช่องว่างของ claim/ฟิลด์ ดู missing_required_claims และ missing_required_fields
missing_required_claims403developers_server.err_missing_required_claims_meaningdevelopers_server.err_missing_required_claims_action
missing_required_fields403developers_server.err_missing_required_fields_meaningdevelopers_server.err_missing_required_fields_action
unknown_required_attributes400developers_server.err_unknown_required_attributes_meaningdevelopers_server.err_unknown_required_attributes_action
business_not_operational403บัญชีธุรกิจถูกล็อก เก็บถาวร หรือไม่สามารถใช้งานได้ติดต่อเจ้าของธุรกิจหรือฝ่ายสนับสนุนของ Checkify อย่าอนุญาตให้ดำเนินการที่ได้รับการป้องกันจนกว่าบัญชีจะเปิดใช้งาน
validation_errors422การตรวจสอบความถูกต้องของ Schema ในเนื้อหา JSON ไม่ผ่าน (HTTP 422)ตรวจสอบ error.details.validation_errors เพื่อดูข้อความระดับฟิลด์ แก้ไขประเภท request_id, required_claims หรือ required_fields ก่อนลองใหม่อีกครั้ง
rate_limited429มีการตรวจสอบยืนยันข้อมูลมากเกินไปในช่วงเวลาสั้นๆลองใหม่โดยใช้การหน่วงเวลาแบบทวีคูณ ตรวจสอบเฉพาะการกระทำที่ได้รับการป้องกัน ไม่ใช่ทุกครั้งที่ดูหน้าเว็บ
server_error500+ไม่สามารถทำการตรวจสอบ Checkify ให้เสร็จสมบูรณ์ได้เนื่องจากปัญหาเซิร์ฟเวอร์ชั่วคราวลองใหม่สักครั้งหรือสองครั้ง จากนั้นปิดโปรแกรมและบันทึกเหตุการณ์

เว็บฮุคและการตรวจสอบแบบอะซิงโครนัส

ปัจจุบัน การตรวจสอบเซิร์ฟเวอร์เป็นแบบซิงโครนัส: แบ็กเอนด์ของคุณจะตรวจสอบ request_id เมื่อผู้ใช้ส่งการกระทำที่ได้รับการป้องกัน สำหรับขั้นตอนการชำระเงิน การลงทะเบียน และการควบคุมการเข้าถึง นี่คือวิธีการที่แนะนำ เว็บฮุคสำหรับการตรวจสอบทั่วไปไม่จำเป็นสำหรับการผสานรวมมาตรฐาน GoHighLevel และการผสานรวมพันธมิตรอื่นๆ อาจใช้การกำหนดค่าเว็บฮุคขาออกแยกต่างหากในแดชบอร์ดทางธุรกิจ

ข้อผิดพลาดที่พบบ่อย

คำเตือนด้านความปลอดภัย

ถือว่าฟิลด์ที่ซ่อนเป็น reference ที่ไม่น่าเชื่อถือ ไม่ใช่หลักฐาน ต้องยืนยันด้วย site API key บนเซิร์ฟเวอร์ก่อนให้สิทธิ์เข้าถึง ใช้ consume: true สำหรับการดำเนินการครั้งเดียว เช่น สมัครสมาชิกหรือรีเซ็ตรหัสผ่าน

ขั้นตอนต่อไป