# GoChat — ผลการค้นคว้าและแบบระบบศูนย์กลางแชท

ตรวจสอบแหล่งข้อมูลวันที่ **7 กันยายน 2026** เอกสารนี้เป็นผลวิเคราะห์และข้อเสนอการออกแบบ การมี API ทางการในตารางไม่ได้หมายความว่า adapter นั้นพัฒนาเสร็จหรือบัญชีจริงผ่านการเชื่อมต่อแล้ว ต้องตรวจสถานะการพัฒนาควบคู่กับผลทดสอบของโครงการ

## ขอบเขตที่ทำได้จริง

GoChat สามารถเป็นเว็บกลางสำหรับรับ อ่าน มอบหมาย และตอบบทสนทนาจากหลายแพลตฟอร์มและหลายบัญชี โดยเชื่อมแต่ละบัญชีผ่านสิทธิ์ที่เจ้าของบัญชีอนุญาต แต่ไม่สามารถรับประกัน “ทุกค่ายทุกบัญชี” ได้ด้วย public API ชุดเดียว เพราะหลายค่ายเปิดเฉพาะบัญชีธุรกิจ เพจ หรือ bot บางค่ายต้องผ่านการตรวจแอป และบางค่ายไม่มี public inbox API สำหรับบัญชีส่วนตัว

คำว่า “หลายบัญชี” ควรหมายถึงเพิ่ม connection ได้หลายรายการ เช่น LINE OA สาขา A และ B, Facebook Page ร้าน A และ B, Telegram bot ทีมขาย และ Slack หลาย workspace แต่ละ connection มี credential, ขอบเขตข้อมูล, quota และสถานะของตนเอง ห้ามถือว่า user ID จากคนละแพลตฟอร์มหรือคนละบัญชีเป็นคนเดียวกันโดยอัตโนมัติ

## ตารางความเป็นไปได้

| ช่องทาง | บัญชี/วิธีเชื่อมต่อทางการ | ข้อจำกัดสำคัญ | ลำดับเสนอ |
|---|---|---|---|
| LINE | LINE Official Account + Messaging API + HTTPS webhook | ไม่ใช่ inbox LINE ส่วนตัว; reply token ใช้ครั้งเดียวและควรใช้ทันที ภายใน 1 นาที; การส่ง push ขึ้นกับสิทธิ์ผู้รับและ quota [L1][L2] | ระยะ 1 |
| TikTok | Business Account + Business Messaging API + authorization/webhook | มี API รับ–ส่ง DM และจัดการ conversations; ต้องตรวจสิทธิ์บัญชี/แอปและกระบวนการ review ก่อนใช้จริง ไม่ถือว่ารองรับ personal DM หรือ TikTok Shop customer service โดยอัตโนมัติ [TK1][TK2] | มีตัวเชื่อมต่อ Business Messaging / รอสิทธิ์และทดสอบจริง |
| Facebook Messenger | Facebook Page + Page access token + `pages_messaging` | ไม่ใช่ Messenger ส่วนตัว; ผู้รับต้องคุยกับ Page; หน้าต่างตอบมาตรฐาน 24 ชั่วโมง และกลไกส่งนอกช่วงต้องตรงเงื่อนไขแพลตฟอร์ม [M1] | ระยะ 1 |
| Instagram | Business/Creator + Instagram Login หรือ Facebook Login | Instagram Login ไม่ต้องผูก Page; Facebook Login ต้องผูก Page; สิทธิ์/host ต่างกัน; DM API ไม่ใช่บัญชี consumer และไม่รองรับ group messaging [I1][I2] | ระยะ 1 |
| WhatsApp | Cloud API + Business Portfolio + WABA + หมายเลขธุรกิจ | ไม่ใช่ดึง inbox WhatsApp ส่วนตัว; free-form ภายใน 24 ชั่วโมงจากข้อความลูกค้าล่าสุด เกินช่วงใช้ template ที่ได้รับอนุมัติ; การใช้งานหมายเลขเดิมร่วมกับแอปต้องตรวจ eligibility/onboarding จริง [W1][W2] | ระยะ 1 |
| Telegram Bot | BotFather token + webhook หรือ long polling | แยกจากบัญชีคน; bot เริ่มคุยกับผู้ใช้เองไม่ได้; เห็นข้อความตามสมาชิกและ privacy mode; webhook กับ long polling ใช้พร้อมกันไม่ได้ [T1][T2] | ระยะ 1 |
| Telegram ส่วนตัว | Telegram API / TDLib + `api_id`/`api_hash` + การเข้าสู่ระบบของผู้ใช้ | ต้องมี session แยกต่อบัญชีและรองรับ code/2FA; เป็นงาน client integration อีกชุด ไม่ใช่ใส่ bot token แล้วได้ inbox ส่วนตัว [T3] | ระยะ 3 |
| Slack | App OAuth ราย workspace + Events API + Web API | เห็นเฉพาะ resource ที่ token มีสิทธิ์; bot ส่งเป็น bot; user token เป็นอีกโหมด; ไม่มีสิทธิ์อ่าน DM ทุกคนเพียงเพราะติดตั้ง app [S1][S2] | ระยะ 1 |
| Discord | Bot install + Gateway events + REST | การอ่านเนื้อหาบางประเภทต้อง `MESSAGE_CONTENT` privileged intent; การใช้ self-bot กับบัญชีผู้ใช้ทั่วไปถูกห้ามในเอกสารแพลตฟอร์ม [D1][D2] | ระยะ 2 |
| Microsoft Teams | Teams app/bot หรือ Microsoft Graph สำหรับองค์กร | Graph การส่งในนามผู้ใช้ต้อง delegated permission ที่ตรง endpoint; app-only ของ send chatMessage ใช้สำหรับ migration ไม่ใช่ทางลัดให้ตอบทุกแชท; การอ่านทั้งองค์กรต้องสิทธิ์/admin consent [MS1][MS2] | ระยะ 2 |
| Google Chat | Chat app หรือ OAuth ผู้ใช้ + Chat API; Workspace Events API | resource ที่เห็นขึ้นกับ identity/scopes; incoming webhook ส่งอย่างเดียว; การรับกิจกรรมทั้งหมดต้องออกแบบ subscription/Pub/Sub และสิทธิ์ที่เกี่ยวข้อง [G1][G2] | ระยะ 2 |
| Email | IMAP/SMTP OAuth2 หรือ Gmail API / Microsoft Graph | mailbox แต่ละบัญชีต้องอนุญาต; Gmail read scopes เป็น restricted จึงมีข้อกำหนด verification/assessment และข้อยกเว้นตาม use case; tenant อาจปิด SMTP AUTH [E1][E2][E3] | ระยะ 2 |
| Viber | Commercial bot + token + webhook | สมัคร bot เชิงพาณิชย์; ปกติส่งให้ผู้สมัครรับข้อความ มี welcome message เป็นข้อยกเว้น; ไม่ใช่ inbox บัญชีส่วนตัว [V1] | ระยะ 3 |
| Zalo | Zalo Official Account OpenAPI และ ZBS Template Message | ต้องมี OA และสิทธิ์ app; social login ไม่ใช่การเข้าถึง personal inbox; เงื่อนไขประเภทข้อความ ช่วงเวลาและค่าบริการแยกกัน [Z1][Z2] | ระยะ 3 |
| WeChat / Weixin | ประเมิน Official Account API ตามประเภทบัญชีและ region | ต้องตรวจ developer console, verification และสิทธิ์จริงก่อนยืนยัน; หน้ารายละเอียดทางการเปิดอ่านไม่ได้ในการค้นครั้งนี้ จึงยังไม่รับรองช่วงเวลาส่งหรือ API access [C1] | รอยืนยัน |
| X Direct Messages | User OAuth + DM API; Account Activity webhook ถ้ามีสิทธิ์ | `dm.read`/`dm.write`; docs ปัจจุบันระบุ pay-per-use; event subscriptions และ quota เป็นเงื่อนไขเพิ่มเติม ไม่ใช่ unlimited accounts [X1][X2][X3] | ระยะ 3 |
| Apple Messages for Business | ช่องทางธุรกิจผ่านกระบวนการของ Apple | เป็นการคุยกับธุรกิจใน Messages; ไม่ใช่ server API สำหรับอ่าน iMessage ส่วนตัวทั้งหมด; ตรวจช่องทางสมัครและผู้ให้บริการก่อนเพิ่ม adapter [A1][A2] | ประเมินธุรกิจ |
| iMessage ส่วนตัว | ยังไม่พบ public server inbox API ในเอกสารที่ตรวจ | iMessage extensions ใช้เพิ่มความสามารถภายใน Messages; ไม่ใช่สิทธิ์อ่าน/ตอบทุกบทสนทนาจากเว็บ GoChat [A1] | ไม่รองรับในรุ่นนี้ |
| Signal | เอกสารทางการเป็น protocol/specification/library | จากเอกสารที่ตรวจยังไม่พบ public business inbox API สำหรับใช้เป็น connector; อย่าสับสน Signal Protocol กับสิทธิ์เข้าถึง Signal account [SG1] | ไม่รองรับในรุ่นนี้ |
| Web chat ของ GoChat | Widget / visitor session / HTTPS API ที่เราออกแบบเอง | ควบคุมการรับส่งและประวัติได้เอง; ต้องแยก session ผู้เยี่ยมชมและป้องกันการอ่านข้ามผู้ใช้ | ระยะ 1–2 |

ข้อมูลด้าน window ควรอยู่ใน policy module ที่เปลี่ยนค่าได้ ไม่ฝังอยู่ใน UI เพียงอย่างเดียว ตัวอย่าง Instagram: standard window 24 ชั่วโมง; `HUMAN_AGENT` อนุญาตคนตอบภายใน 7 วันเมื่อได้รับสิทธิ์ ห้ามนำโหมดนี้ไปใช้กับข้อความอัตโนมัติหรือเนื้อหาที่ไม่เกี่ยวกับคำถาม [I3]

Zalo มีความเสี่ยงตีความผิด: เอกสาร OA ที่ตรวจแยก “เงื่อนไขการส่ง” ออกจาก “ช่วงข้อความฟรี” จึงไม่ควรตีความ 48 ชั่วโมงว่าเป็น hard send window ของทุกกรณี ควรตรวจนโยบายล่าสุดและ package ของ OA ก่อนลงระบบคิดสิทธิ์ส่ง [Z2]

## สถาปัตยกรรมที่เสนอ

ใช้ Go `net/http`, `html/template`, CSS และ JavaScript ปกติสำหรับเว็บ พร้อม SQLite เป็นฐานข้อมูลหลัก ให้ระบบรันเป็น process เดียวในช่วงแรก แยก interface ของ storage และ adapter เพื่อขยายภายหลัง

```mermaid
flowchart LR
    P[แพลตฟอร์มแชท] -->|Webhook / Poll / Gateway| A[Adapter แยกรายค่าย]
    A --> V[ตรวจลายเซ็นและแยกบัญชี]
    V --> DB[(SQLite)]
    DB --> N[Normalize และ deduplicate]
    N --> IN[Unified inbox]
    IN --> UI[GoChat เว็บ]
    UI --> Q[บันทึกข้อความและ outbox]
    Q --> POL[ตรวจสิทธิ์ส่งและ window]
    POL --> A
    A -->|Send API| P
    P -->|สถานะส่ง / อ่าน ถ้ามี| A
```

1. **Connection registry:** กำหนด provider และ account identity ให้ชัด เช่น page ID, IG account ID, WABA phone number ID, LINE channel/OA ID, Slack team ID เก็บ credential ฝั่ง server แบบเข้ารหัส และไม่คืน token ผ่าน API รายการบัญชี
2. **รับข้อความอย่างทนทาน:** ตรวจ provider signature/secret จาก raw body, จำกัดขนาด request, บันทึก event แล้วตอบรับรวดเร็ว นำ event เข้าประมวลผลซ้ำได้โดยมี unique key `(connection_id, provider_event_id)` ไม่ให้ข้อความซ้ำจาก webhook retry
3. **โครงข้อความกลาง:** เก็บ provider message ID, remote conversation ID, sender identity, direction, timestamp, text, attachments, reply-to, raw event และสถานะ ข้อมูลที่ provider ไม่ส่งต้องแสดงว่าไม่มีข้อมูล ไม่สร้าง read/delivered เอง
4. **การส่งข้อความ:** บันทึก local message และ outbox ใน transaction เดียว แล้วให้ worker ส่งจริง สถานะอย่างน้อย `queued`, `sending`, `accepted`, `delivered`, `read`, `failed`, `unknown`; HTTP 200 จาก provider บางค่ายหมายถึงรับคำขอ ไม่รับประกันผู้รับอ่านหรือได้รับแล้ว
5. **รับมือส่งซ้ำ:** ใช้ idempotency key ที่ provider รองรับ แยก timeout ที่ยังไม่ทราบผลเป็น `unknown` ไม่ retry โดยไม่ตรวจ เพราะคำขอแรกอาจสำเร็จไปแล้ว; สำหรับ 429 ใช้ Retry-After/backoff และคิวรายบัญชี
6. **Policy per connection:** ก่อนส่งตรวจ last inbound time, template requirement, token expiry, quota, provider capability และสิทธิ์ agent; ปิดฟีเจอร์ที่ยังไม่รองรับแทนการแสดงว่าส่งสำเร็จ
7. **งานทีม:** assignment, open/pending/resolved, internal note, tag, ค้นหา, canned replies, audit trail; internal note ต้องไม่มีทางหลุดไป outbox ภายนอก
8. **อัปเดตหน้าเว็บ:** ใช้ SSE หรือ polling แบบ cursor ให้หน้า inbox เห็น event ใหม่โดยไม่ต้องมี frontend framework; ผูกทุก request กับ user session และสิทธิ์บัญชี

โครงข้อมูลหลักที่เสนอ: `users`, `sessions`, `teams`, `connections`, `connection_credentials`, `contacts`, `contact_identities`, `conversations`, `conversation_participants`, `messages`, `attachments`, `inbound_events`, `outbox_jobs`, `audit_events` และ `provider_cursors` หากรุ่นแรกใช้ workspace เดียว ต้องระบุชัดและไม่แสดงว่าเป็น multi-tenant ที่แยกองค์กรได้แล้ว

SQLite เหมาะกับระบบที่วาง application และฐานข้อมูลบนเครื่องเดียว เอกสารระบุว่ามี writer ได้ครั้งละหนึ่งราย; WAL ช่วยให้ผู้อ่านทำงานขณะเขียนได้ แต่ไม่เปลี่ยนเป็นหลาย writer พร้อมกัน จึงควรใช้ transaction สั้น, busy timeout, index ตาม inbox/search, คิวจำกัด concurrency และ backup ด้วยกลไกที่สอดคล้องกับ WAL หลีกเลี่ยงวางไฟล์ฐานข้อมูลบน network filesystem [DB1][DB2]

## หน้าจอที่ต้องมี

| หน้า | สิ่งที่ผู้ใช้ต้องทำได้ |
|---|---|
| กล่องข้อความ | รวมทุกบัญชีที่มีสิทธิ์, กรองค่าย/บัญชี/ผู้รับผิดชอบ/สถานะ, ค้นหา, เห็น unread |
| บทสนทนา | อ่านประวัติ, ตอบจากบัญชีต้นทางที่ถูกต้อง, เห็นสถานะส่งจริง, เปลี่ยนผู้รับผิดชอบ, บันทึกภายใน |
| การเชื่อมต่อ | เพิ่มหลายบัญชีในค่ายเดียว, ตรวจ credential, แสดง webhook URL/ขั้นตอนตั้งค่า, สถานะรออนุญาต/พร้อมใช้/ผิดพลาด |
| ความสามารถช่องทาง | บอกว่ารับ/ส่ง/แนบไฟล์/ดึงประวัติได้หรือยัง และชนิดบัญชีที่รองรับ |
| ผู้ใช้และสิทธิ์ | owner/admin/agent, ระบุบัญชีที่เข้าถึง, ดู audit ตามสิทธิ์ |
| งานส่งและสุขภาพระบบ | pending/failed/unknown, reason ที่แก้ได้, webhook ล่าสุด, token expiry, quota เมื่อ provider ให้ข้อมูล |

ปุ่ม “เพิ่มบัญชี” ไม่ควรทำให้สถานะกลายเป็น “เชื่อมต่อแล้ว” เพียงเพราะมี row ใน SQLite ควรแยกอย่างน้อย `draft`, `configured`, `verified`, `receiving`, `error`, `disabled` และระบุว่าการตรวจ token ผ่านยังไม่ใช่การทดสอบรับข้อความจริง

## แผนพัฒนาและการเปิดใช้

**ระยะ 1 — ระบบกลางและช่องทางหลักไทย:** unified inbox, user login, multi-account isolation, credential protection, webhook verification, deduplication, text replies, delivery/error state และ adapters LINE OA, Telegram Bot, Messenger Page, Instagram Professional, WhatsApp Cloud, Slack โดยโหมด demo ต้องมีป้ายกำกับและไม่ส่งออกจริง

**ระยะ 2 — ใช้งานทีมและประวัติ:** OAuth onboarding, token refresh, audit/permission, durable outbox + retry/reconciliation, attachments, contact matching แบบผู้ใช้ยืนยัน, import history เฉพาะ API ที่รองรับ, Email, Discord, Teams, Google Chat, web widget พร้อม retention/backup/restore และ deployment ที่มี HTTPS

**ระยะ 3 — ขยายบัญชีและภูมิภาค:** Telegram TDLib แยก service/session, Viber commercial, Zalo, X และ WeChat ที่ตรวจสิทธิ์จริงแล้ว ต่อ Apple Messages for Business เฉพาะเมื่อผ่านขั้นตอนเข้าร่วม/ผู้ให้บริการที่เกี่ยวข้อง

จำนวนช่องทางที่แสดงใน catalog ไม่ใช่เกณฑ์ความสำเร็จ เกณฑ์เปิดใช้แต่ละ adapter ต้องเป็น “ลูกค้าส่งจากแอปจริง → GoChat รับข้อความตรงบัญชี → agent ตอบ → ผู้รับเห็นในแอปเดิม → สถานะและข้อมูลยังถูกหลังรีสตาร์ต”

## สิ่งที่ต้องเตรียมก่อนทดสอบบัญชีจริง

| กลุ่ม | ข้อมูลและงานที่ต้องทำ |
|---|---|
| ทุกช่องทาง | เจ้าของบัญชีที่อนุญาต, URL HTTPS สาธารณะ, callback/webhook, app identity, token/scopes, account ID, ผู้รับทดสอบที่ยินยอม, เงื่อนไขส่งและ media |
| LINE | OA + Messaging API channel, channel secret/access token, เปิด webhook, ตรวจการตอบอัตโนมัติเดิมว่าไม่ชนกับ GoChat |
| Telegram | bot token จาก BotFather, setWebhook พร้อม secret token หรือ polling, ส่ง `/start` จากผู้รับ; สำหรับบัญชีส่วนตัวทำ login/2FA flow อีกชุด |
| Meta | app, Page/IG/WABA identifiers ตามค่าย, token/scopes, webhook verify token และ app secret, subscription, app role/testers ระหว่าง development; กรณีให้บัญชีบุคคลอื่นใช้ต้องเตรียม access review ตาม use case |
| Slack | app install ราย workspace, `chat:write`, read/history scopes ที่จำเป็นตามชนิด conversation, Events subscriptions, signing secret, channel membership |
| Teams / Google Chat | organization/tenant หรือ Google Cloud project, admin ที่อนุญาตตามสิทธิ์, OAuth consent และ app install, subscription renewal |
| Email | mailbox permission, OAuth app, scopes ขั้นต่ำ, refresh token lifecycle, receive cursor, SMTP/Graph/Gmail send, threading ด้วย Message-ID/In-Reply-To |
| Viber / Zalo / X / WeChat | commercial/access enrollment ตามค่าย, region/package, developer app, account approval, quota/billing และ test recipient |

การป้อน secrets ควรทำในหน้าตั้งค่าที่ส่งตรง server ผ่าน HTTPS หรือ secret file บน server ไม่ส่งในบทสนทนา ไม่ใส่ใน Git ไม่แสดงใน log และเมื่อกดลบบัญชีต้อง revoke/unsubscribe ที่ทำได้พร้อมยุติงานคิวของบัญชีนั้น

## การทดสอบที่ต้องผ่าน

- แยกข้อมูลของ OA/Page/workspace สองบัญชี แม้ remote user ID หรือ message ID ชนกัน
- webhook ที่ลายเซ็นผิดถูกปฏิเสธ; payload ซ้ำบันทึกครั้งเดียว; ข้อมูลจาก event จริงตรง schema กลาง
- internal note อยู่ภายใน; demo reply ไม่เรียก provider; connection ที่ยังไม่ได้ verify ไม่อ้างว่าพร้อมใช้
- token หมดอายุ, provider 401/403/429/5xx, timeout และ response body ที่ผิดรูปแบบแสดงสถานะที่แก้ปัญหาได้
- เกิน messaging window ต้องถูกห้ามหรือเสนอ template/ช่องทางที่มีสิทธิ์จริง; ยังไม่รองรับ template ต้องบอกตรง ๆ
- restart ระหว่างรับ/ส่งต้องไม่สูญข้อความที่ตอบรับแล้ว และไม่ยิงซ้ำโดยไม่รู้ผล
- ผู้ใช้ออกจากระบบแล้วเข้าถึง inbox/credentials ไม่ได้; agent ที่ไม่มีสิทธิ์บัญชีไม่สามารถอ่านหรือส่งผ่าน ID ที่เดาได้
- ทดลองจากแอปจริงแต่ละค่ายอย่างน้อยหนึ่ง round trip และหลายบัญชีในค่ายเดียวก่อนระบุว่าใช้งานจริงได้

## แหล่งข้อมูลทางการ

ลิงก์ทั้งหมดตรวจวันที่ 7 กันยายน 2026 เว้นแต่ระบุว่าเปิดอ่านไม่ได้ ใช้ Meta official Postman collections ในรายการ Meta เพราะ developers.facebook.com หลายหน้าตอบข้อผิดพลาดในเครื่องมือค้นครั้งนี้ วันที่ crawl ไม่ใช่วันที่แก้ไขนโยบาย จึงควรตรวจซ้ำตอนเปิดใช้งานจริง

- [L1] [LINE Messaging API reference](https://developers.line.biz/en/reference/messaging-api/nojs/) — reply token, webhooks, rate limits
- [L2] [LINE Send messages](https://developers.line.biz/en/docs/messaging-api/sending-messages) — reply/push/broadcast
- [M1] [Meta Messenger Send API](https://www.postman.com/meta/messenger-platform-api/folder/7cc3gd2/send-api) — Page token, permission, standard window
- [I1] [Meta Instagram API](https://www.postman.com/meta/workspace/instagram/documentation/23987686-9386f468-7714-490f-9bfc-9442db5c8f00) — professional accounts, Instagram Login, messaging limits
- [I2] [Meta Instagram Conversations API](https://www.postman.com/meta/instagram/folder/23987686-6a91368f-1fa8-4614-9ed6-7d1e08c21e62) — Standard/Advanced Access
- [I3] [Meta Instagram API / Human Agent](https://www.postman.com/meta/instagram/documentation/6yqw8pt/instagram-api?entity=request-23987686-af579d08-121e-4897-8f45-5fd41ace49df) — 24-hour standard / 7-day human agent and approval
- [W1] [Meta WhatsApp Cloud API](https://www.postman.com/meta/whatsapp-business-platform/documentation/wlk6lh4/whatsapp-cloud-api) — business assets and permissions
- [W2] [Meta WhatsApp status object / customer support window](https://www.postman.com/meta/whatsapp-business-platform/folder/fuaee8l/statuses-object) — 24-hour rolling customer window; ใช้เฉพาะข้อกำหนดส่ง ไม่ใช่ข้อมูลราคา conversation เก่าในหน้านี้
- [T1] [Telegram Bots introduction](https://core.telegram.org/bots) — bot cannot start conversation
- [T2] [Telegram Bots FAQ](https://core.telegram.org/bots/faq) — privacy, webhook/polling
- [T3] [Telegram TDLib getting started](https://core.telegram.org/tdlib/getting-started) — user authorization and local session database
- [S1] [Slack Events API](https://docs.slack.dev/apis/events-api/) — scopes and visibility
- [S2] [Slack chat.postMessage](https://docs.slack.dev/reference/methods/chat.postMessage/) — identity, chat:write and membership
- [D1] [Discord Gateway](https://docs.discord.com/developers/events/gateway) — privileged intents
- [D2] [Discord Automated User Accounts](https://support.discord.com/hc/en-us/articles/115002192352-Automated-User-Accounts-Self-Bots) — self-bot policy
- [MS1] [Microsoft Graph send chatMessage](https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0) — ตรวจ permission ของ endpoint/version ก่อนนำไปใช้
- [MS2] [Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference) — ChatMessage.Send and ChatMessage.Read.All
- [G1] [Google Chat authentication](https://developers.google.com/workspace/chat/authenticate-authorize) — user/app scopes and resource visibility
- [G2] [Google Workspace Chat event subscriptions](https://developers.google.com/workspace/events/guides/events-chat) — event model
- [E1] [Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes) — หน้าแสดง last updated 2026-07-22 UTC
- [E2] [Google restricted-scope verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification) — verification, assessment, exceptions
- [E3] [Exchange OAuth for IMAP/POP/SMTP](https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth) — Microsoft 365/Outlook OAuth
- [V1] [Viber REST API](https://developers.viber.com/docs/api/rest-bot-api/) — commercial bots and subscriber messaging
- [Z1] [Zalo developer documentation](https://developers.zalo.me/docs) — OA, ZBS, Social are separate products
- [Z2] [Zalo OA message policy](https://oa.zalo.me/home/resources/news/thong-bao-chinh-sach-gui-tin-va-quy-dinh-phi-gui-tin_1433049880779375099) — source policy is older; recheck current package before implementing prices/windows
- [C1] [Weixin Official Account documentation](https://developers.weixin.qq.com/doc/offiaccount/Getting_Started/Overview.html) — เครื่องมือเปิดอ่านรายละเอียดไม่ได้ จึงระบุเป็นจุดตรวจต่อ ไม่ใช่ข้อเท็จจริงที่ยืนยันแล้ว
- [X1] [X DM quickstart](https://docs.x.com/x-api/direct-messages/manage/quickstart) — OAuth2 PKCE and scopes
- [X2] [X pricing](https://docs.x.com/x-api/getting-started/pricing) — pay-per-use; ไม่ตรึงราคาใน GoChat
- [X3] [X Account Activity API](https://docs.x.com/x-api/account-activity/introduction) — webhook and subscription tiers
- [A1] [Apple iMessage Apps and Stickers](https://developer.apple.com/imessage/) — extension vs Messages for Business
- [A2] [Apple Messages for Business](https://support.apple.com/en-mide/102053) — customer/business conversation
- [SG1] [Signal technical documentation](https://signal.org/docs/) — protocol specifications and libraries
- [DB1] [SQLite appropriate uses](https://sqlite.org/whentouse.html) — deployment/concurrency fit
- [DB2] [SQLite WAL](https://sqlite.org/wal.html) — read/write behavior and network filesystem restriction

## เพิ่มเติม: TikTok และ Facebook

ตรวจเพิ่มตามคำขอวันที่ 7 กันยายน 2026: ใน GoChat ชื่อ Facebook Messenger หมายถึง inbox ของ Facebook Page ตัวเชื่อมต่อรับ–ส่งข้อความมีแล้ว แต่การเชื่อมต่อจริงต้องได้รับ Page token และสิทธิ์ของเจ้าของเพจ สามารถเพิ่มหลายเพจเป็นคนละบัญชีได้ ไม่ใช่การรวม inbox ของ Facebook profile ส่วนตัวทั้งหมด

TikTok Business Messaging API มีความสามารถรับ–ส่งข้อความ จัดการบทสนทนา และ webhook จากเอกสารทางการ จึงเป็นเส้นทางที่สามารถนำมาพัฒนาตัวเชื่อมต่อได้ ปัจจุบันเพิ่ม adapter รับ webhook, ส่งข้อความ, ตรวจ token, ต่ออายุและตั้ง callback แล้ว รายละเอียดล่าสุดอยู่ที่ [คู่มือ TikTok](/docs/tiktok) ต้องผ่าน developer/app review และอนุญาตบัญชีจริงก่อนเริ่มใช้งาน

TikTok Shop customer service เป็นกรณีใช้งานแยก ต้องตรวจ Seller/Partner API และสิทธิ์ร้านค้า ไม่ควรใช้ Business Messaging API หรือ token ชุดเดียวกันโดยสมมติว่าเข้าถึงข้อมูลทั้งสองแบบได้

TikTok Data Portability API ให้ขอข้อมูลประวัติ DM เพื่อ export ตามขอบเขตที่ได้รับอนุญาต ไม่ใช่ API สำหรับตอบแชทส่วนตัวแบบ real-time และเอกสารระบุครอบคลุมข้อมูลผู้ใช้ EEA/UK จึงใช้แทน inbox connector สำหรับบัญชีไทยทั่วไปไม่ได้ [TK3]

- [TK1] [TikTok About API for Business](https://ads.tiktok.com/help/article/marketing-api?lang=en) — Business Messaging API รองรับรับ–ส่งข้อความและจัดการ message threads
- [TK2] [TikTok Business API reference](https://business-api.tiktok.com/gateway/docs/index?doc_id=1825017307843585&language=ENGLISH) — navigation/reference แยก send message, conversations, messages, capability และ webhook; รายละเอียด access ต้องตรวจ developer portal ที่ได้รับสิทธิ์
- [TK3] [TikTok Data Portability API](https://developers.tiktok.com/products/data-portability-api/) — export scopes และขอบเขต EEA/UK