ยืนยัน SMS อัตโนมัติด้วย API: คู่มือฉบับสมบูรณ์

หน้าเว็บใช้งานได้ดีถ้าคุณสมัครแค่เป็นครั้งคราว คลิกไม่กี่ครั้ง รอ SMS หนึ่งข้อความ แต่พอคุณต้องเขียน automated test สคริปต์สมัครสมาชิกจำนวนมาก CI pipeline หรือบอทที่ต้องรับรหัสยืนยันเองโดยไม่มีคนเฝ้า หน้าเว็บก็ใช้ไม่ได้อีกต่อไป หน้าเว็บทำแบบนั้นไม่ได้ แต่ API ทำได้ บทความนี้รวมทุกอย่างที่คุณต้องรู้เพื่อเริ่มจากศูนย์จนได้ flow ที่ใช้งานได้จริง

ขั้นตอนที่ 1: รับ API key

เข้าสู่ระบบแล้วไปที่ /account/api-keys เพื่อสร้าง key ใหม่ key จะมีรูปแบบ jm_ ตามด้วยสตริงสุ่ม ข้อความเต็มจะแสดงให้เห็นครั้งเดียวเท่านั้น — สิ่งที่เราเก็บไว้คือ hash ไม่ใช่ key ตัวจริง ดังนั้นจะไม่มีตัวเลือก "กู้คืน key ของฉัน" ถ้าคุณทำหาย ลบทิ้งแล้วสร้างใหม่ได้เลย

ทุก request ใช้การยืนยันตัวตนแบบ Bearer มาตรฐาน:

Authorization: Bearer jm_your_key

ให้ปฏิบัติกับ key เหมือนรหัสผ่าน — ห้าม commit ขึ้น repo สาธารณะ ห้ามวางในแชทเพื่อให้คนอื่นช่วย debug ถ้าสงสัยว่า key รั่วไหล ให้กลับไปที่ /account/api-keys ลบทิ้ง แล้วสร้างใหม่ key เก่าจะหยุดทำงานทันที

ขั้นตอนที่ 2: เลือก service และประเทศ

การสร้าง order ต้องมีสองอย่าง: service (โค้ด service) และ country (id ประเทศ) เริ่มจากดูรายการ catalog ก่อน:

curl https://jiema.my/api/v1/services \
  -H "Authorization: Bearer jm_your_key"

แต่ละรายการจะมี field code (Telegram คือ tg) — ส่งค่านี้ตรง ๆ ไปยัง endpoint สำหรับสร้าง order น่าเชื่อถือกว่าการมาประกอบ slug เอง ถ้าต้องการดูราคาและสต็อกแบบเรียลไทม์ของ service หนึ่งในแต่ละประเทศ ให้เพิ่มพารามิเตอร์ service:

curl "https://jiema.my/api/v1/prices?service=tg" \
  -H "Authorization: Bearer jm_your_key"

แต่ละรายการใน items จะมี countryId / priceCents / count (จำนวนเบอร์ที่ใช้ได้ตอนนี้) ตรวจสอบ count ก่อนสั่ง order — ถ้าเป็นศูนย์ order จะล้มเหลวแน่นอน อย่าเสีย request ไปเพื่อรู้เรื่องนี้แบบยาก ๆ

ขั้นตอนที่ 3: สร้าง order

curl -X POST https://jiema.my/api/v1/orders \
  -H "Authorization: Bearer jm_your_key" \
  -H "Content-Type: application/json" \
  -d '{"service":"tg","country":"6"}'

order ที่สำเร็จจะคืนเบอร์โทรศัพท์และเวลาหมดอายุมาให้:

{
  "ok": true,
  "data": {
    "id": "cm...",
    "status": "WAITING",
    "phone": "62812xxxxxxx",
    "expiresAt": "2026-08-01T12:15:00.000Z",
    "chargedCents": "40"
  }
}

เงินจะถูกหักตอนนี้เลย — chargedCents คือจำนวนที่ถูกหักจริง (หน่วยเป็นสตางค์) ส่งเบอร์นี้ให้แอปปลายทางเพื่อรับรหัสยืนยัน แล้วไปขั้นตอนต่อไป

ขั้นตอนที่ 4: Polling เพื่อรับรหัส

ไม่มี WebSocket หรือ webhook push ให้ใช้ — วิธีรับเนื้อหา SMS คือ polling GET /api/v1/orders/:id ไปเรื่อย ๆ จนกว่า smsBody จะไม่เป็น null อีกต่อไป:

while true; do
  RESP=$(curl -s https://jiema.my/api/v1/orders/$ORDER_ID \
    -H "Authorization: Bearer jm_your_key")
  BODY=$(echo "$RESP" | jq -r '.data.smsBody')
  if [ "$BODY" != "null" ]; then
    echo "Code received: $BODY"
    break
  fi
  sleep 5
done

ห้าวินาทีต่อครั้งเป็นจุดเริ่มต้นที่สมเหตุสมผล — เบอร์มีอายุใช้งาน 15 นาที และ limit 60 request/นาทีสำหรับการ query ก็ยังเหลือพื้นที่เยอะ สามวินาทีก็ยังพอไหวถ้าคุณใจร้อน แต่ polling ทุกวินาทีไม่ได้ทำให้รหัสมาเร็วขึ้น มีแต่จะเปลืองโควต้า rate limit ของคุณ

ข้อควรระวัง

• ขีดจำกัด rate นับตาม user ไม่ใช่ตาม key endpoint สำหรับเขียน (order / cancel / next-sms) จำกัดที่ 10 ครั้ง/นาทีต่อ user endpoint สำหรับอ่านอยู่ที่ 60 ครั้ง/นาที การสร้าง key เพิ่มไม่ได้ทำให้เพดานสูงขึ้น — ทุก key ใช้โควต้าเดียวกัน
• เบอร์จะหมดอายุหลัง 15 นาที เบอร์ที่ไม่ได้ใช้และหมดอายุโดยไม่ได้รับรหัสจะได้รับเงินคืนอัตโนมัติ ไม่ต้องขอ แต่ถ้า pipeline ของคุณเก็บเบอร์นั้นไว้นานเกินไปก่อนจะเอาไปใช้จริง (เช่น ติดอยู่ใน queue) เบอร์ก็จะหมดอายุไปก่อนที่จะถึงตาคุณใช้
• เบอร์เดียวรับได้มากกว่าหนึ่งรหัส ถ้าแอปปลายทางส่ง SMS เป็นสองขั้นตอน (ยืนยันการสมัครก่อน แล้วค่อยส่งรหัส login แยกอีกที) ให้เรียก POST /api/v1/orders/:id/next-sms หลังจากได้รับรหัสแรก เพื่อบอกเราว่า "อันนี้จบแล้ว รอฟังต่อได้เลย" ไม่ต้องสร้าง order ใหม่เพื่อขอเบอร์ใหม่
• พอรหัสมาถึงแล้ว cancel จะใช้ไม่ได้อีก POST /api/v1/orders/:id/cancel จะคืนเงินให้ทันทีตราบใดที่เบอร์ยังรอรหัสอยู่ แต่ถ้า smsBody เคยไม่เป็น null มาก่อนแล้ว การเรียกแบบเดียวกันนี้จะคืน error CODE_RECEIVED มาแทน — คุณได้รับสิ่งที่จ่ายเงินไปแล้ว จึงย้อนกลับไม่ได้อีก
• อย่าเช็ก status แค่ครั้งเดียวแล้วเลิก status จะเปลี่ยนจาก WAITING ไปเป็น RECEIVED ถ้ามันค้างอยู่ที่ WAITING จนหมดอายุ ส่วนใหญ่มักเป็นเพราะอัตราการส่ง SMS สำเร็จของประเทศ/service คู่นั้นกำลังต่ำอยู่ — สร้าง order ใหม่ในอีกประเทศมักได้ผลเร็วกว่าการรอเฉย ๆ

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

ที่กล่าวมาคือ flow หลักตั้งแต่สร้าง order จนได้รหัส ส่วนรายการ field ทั้งหมด error code และกรณีปลีกย่อยของแต่ละ endpoint ดูได้ที่ /api-docs ถ้าคุณใช้งานนี้ในสเกลใหญ่ — เช่น ต้องคอยดูแลการยืนยันของหลายสิบบัญชีพร้อมกัน — ให้จับเวลา polling ของแต่ละ order แยกจากกัน อย่าเอาไปเข้าคิวรอทีละตัวใน loop เดียว ไม่งั้นเบอร์ที่ได้มาก่อนจะหมดอายุตั้งแต่ตอนที่คุณยังรอเบอร์แรกอยู่