Authentication
Bearer JWT (dashboard) vs API key (server-to-server) — เลือกใช้แบบไหนเมื่อไร
SlipBolt มี 2 ชนิด credential — ใช้แยกตามบทบาท
Bearer JWT (Dashboard / LIFF)
ผู้ใช้ login ที่ app.slip-bolt.com แล้วได้ JWT access token (TTL 15 นาที) + refresh cookie (sb_rt · 7 วัน · หมุนทุกครั้งที่ใช้)
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
- Refresh อัตโนมัติเมื่อ access token หมดอายุ → useApi composable จัดให้ทั้งหมด
- เหมาะกับ browser / mobile app
API Key (Server-to-server)
สร้างที่ Settings → API Keys — รูปแบบ sk_live_<32 chars>
ต้องใช้แพ็ก Starter ขึ้นไป — ช่วงทดลองใช้ฟรี (Trial) ออก API key ไม่ได้
และคีย์ที่ออกไว้ตอนอยู่แพ็กที่จ่ายเงิน จะถูกปฏิเสธด้วย 403 ทันทีที่แพ็กหมดอายุ
หรือร้านถูกพักใช้งาน (ตรวจทุกคำขอ ไม่ใช่แค่ตอนออกคีย์)
Authorization: Bearer sk_live_a1b2c3d4...
- ไม่หมดอายุ จนกว่าจะ revoke
- สูงสุด 5 คีย์ที่ยังไม่ถูกเพิกถอนต่อร้าน — เพิกถอนใบที่ไม่ใช้ก่อนจึงจะออกใบใหม่ได้
- มี scope จำกัด (default:
verify· เพิ่มread/webhookได้ที่ Settings → API Keys) — ดู API Reference - เก็บใน server environment variable เท่านั้น อย่าใส่ในโค้ด frontend
สิทธิ์ต่อแพ็ก (โควตา · ที่นั่ง · LINE · API)
ร้านแรกช่วงทดลอง 7 วันได้สิทธิ์แถว Trial เท่านั้น — ไม่ใช่แพ็กที่เลือกตอน onboarding
| Plan | สลิป/เดือน | ที่นั่ง | กลุ่ม LINE | LINE OA | REST API |
|---|---|---|---|---|---|
| Trial | 50 | 1 | 1 | 1 | ❌ |
| Starter | 500 | 1 | 1 | 3 | ✅ |
| Pro | 1,500 | 5 | 3 | 10 | ✅ |
| Business | 5,000 | ไม่จำกัด | 10 | ไม่จำกัด | ✅ |
โควตาสลิปเป็น pool เดียวกับสลิปที่เข้าทาง LINE — ใช้ช่องไหนก็หักจากก้อนเดียวกัน
อ่านยอดคงเหลือได้ที่ GET /api/v1/quota · GET /api/v1/me หรือ header X-Slipbolt-Quota-*
(ดู API Reference)
sk_test_ — เลนทดสอบ
คีย์ที่ขึ้นต้นด้วย sk_test_ ไม่กินโควตาสลิปรายเดือนของร้าน ใช้ต่อ integration
ได้โดยไม่เปลืองของที่จ่ายเงินมา · response มี "environment": "test" กำกับ
เลนทดสอบมีเพดาน 200 ครั้ง/ร้าน/เดือน — เพราะมันยังตรวจสลิปกับธนาคารจริงทุกครั้ง
(ไม่ใช่ของจำลอง) เกินเพดานได้ 402 พร้อม code: "TEST_QUOTA_EXCEEDED" (สถานะเดียวกับตอนโควตาของร้านหมด — ทางออกคือย้ายไปคีย์ sk_live_) · นับทุกคำขอ
ที่ยิงเข้ามา ไม่ใช่เฉพาะที่สำเร็จ เพราะค่าใช้จ่ายเกิดตั้งแต่ตอนยิง
Rate limit (เท่ากันทุกแพ็ก)
120 req/min ต่อ 1 API key — นับแบบ fixed window ราย 1 นาที และไม่ได้แยกตามแพ็ก
มีเพดานรวมของ endpoint POST /api/v1/verify อีกชั้นที่ 240 req/min
เกิน → 429 Too Many Requests + header Retry-After: <seconds>
ต้องการเพดานสูงกว่านี้ ติดต่อทีมงาน — ปรับได้ที่ฝั่งเซิร์ฟเวอร์ (API_KEY_RATE_LIMIT_PER_MIN)
ไม่ใช่การอัปเกรดแพ็ก
Error responses
ทุก error envelope เป็นรูปแบบเดียวกัน:
{
"success": false,
"error": "Unauthorized",
"message": "Invalid API key",
"statusCode": 401,
"path": "/api/v1/verify",
"requestId": "req_abc123",
"timestamp": "2026-05-25T12:30:45+07:00"
}
