# ภาพรวม Messaging API v2

Messaging API v2 เป็น REST/JSON endpoint เดียวสำหรับการสร้างข้อความขาออกในทุกช่องทางที่ Pushwoosh รองรับ:

- พุช: iOS, Android, Huawei, Baidu, macOS, Amazon, Windows, Safari, Chrome, Firefox, IE
- อีเมล
- SMS
- Telegram, Kakao, LINE, WhatsApp, Viber

**Channel** ถูกเลือกโดยประเภทของ payload (`payload` สำหรับพุช / SMS / เมสเซนเจอร์, `email_payload` สำหรับอีเมล)

**Targeting** ถูกเลือกโดยประเภทของคำขอ (`segment` สำหรับกลุ่มเป้าหมาย, `transactional` สำหรับรายการอุปกรณ์หรือผู้ใช้ที่ระบุอย่างชัดเจน)

## URL พื้นฐาน

```
https://api.pushwoosh.com
```

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

## การยืนยันตัวตน

ทุกคำขอต้องมีส่วนหัว `Authorization` พร้อมด้วย [API access token](/th/developer/api-reference/api-access-token/#server-api-token) ฝั่งเซิร์ฟเวอร์ของ Pushwoosh:

```
Authorization: Token YOUR_API_TOKEN
```

ใช้โทเค็นเดียวกับที่คุณออกให้สำหรับการเรียก API แบบ server-to-server อยู่แล้ว อย่าเปิดเผยโทเค็นนี้ในแอปพลิเคชันฝั่งไคลเอ็นต์

## เมธอด

- [`Notify`](/th/developer/api-reference/messaging-api-v2/notify/): `POST /messaging/v2/notify` สร้างและส่งข้อความเดียว (แบบ segment หรือ transactional)
- [`Cancel`](/th/developer/api-reference/messaging-api-v2/cancel/): `POST /messaging/v2/cancel` ยกเลิกข้อความที่สร้างไว้ก่อนหน้านี้และยังไม่ได้จัดส่ง
- [`Update`](/th/developer/api-reference/messaging-api-v2/update/): `POST /messaging/v2/update` แทนที่ข้อความที่ยังคงกำหนดเวลาไว้ด้วยคำจำกัดความใหม่

## รูปแบบคำขอและการตอบกลับ

- ประเภทเนื้อหา: `application/json`
- ชื่อฟิลด์ใช้ `snake_case` กลุ่ม `oneof` จะปรากฏเป็นอ็อบเจกต์ที่ซ้อนกันโดยมีการตั้งค่าคีย์เพียงหนึ่งคีย์
- ค่า Enum จะถูกทำให้เป็นอนุกรมเป็นชื่อสตริง (ตัวอย่างเช่น `"IOS"`, `"MESSAGE_TYPE_MARKETING"`)
- การตอบกลับที่สำเร็จจะคืนค่า HTTP 200 พร้อมเนื้อหา JSON; ข้อผิดพลาดจะใช้รูปแบบข้อผิดพลาดมาตรฐานของ gRPC-Gateway — `{ "code": ..., "message": ..., "details": [...] }`

## เริ่มต้นอย่างรวดเร็ว

```bash title="ส่งพุชไปยัง segment"
curl -X POST https://api.pushwoosh.com/messaging/v2/notify \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "segment": {
      "application": "XXXXX-XXXXX",
      "platforms": ["IOS", "ANDROID"],
      "code": "active_users",
      "payload": {
        "content": {
          "localized_content": {
            "en": {
              "ios":     { "body": "Hello from v2!" },
              "android": { "body": "Hello from v2!" }
            }
          }
        }
      },
      "schedule": { "at": "2026-05-01T12:00:00Z" },
      "message_type": "MESSAGE_TYPE_MARKETING"
    }
  }'
```

## การส่งอีเมลผ่าน SMTP

หากบริการพูด SMTP อยู่แล้ว คุณสามารถส่งอีเมลธุรกรรมผ่าน [SMTP gateway](/th/developer/api-reference/smtp-gateway/) แทนการเรียก `Notify` โดยตรง เกตเวย์จะส่งต่อแต่ละข้อความไปยัง API นี้เป็น `Notify` แบบธุรกรรม ดังนั้นกฎการยืนยันตัวตนและ payload ของอีเมลเดียวกันจึงมีผลบังคับใช้

## ขั้นตอนถัดไป

<CardGrid>
  <LinkCard title="Notify" href="/developer/api-reference/messaging-api-v2/notify/" />
  <LinkCard title="Cancel" href="/developer/api-reference/messaging-api-v2/cancel/" />
  <LinkCard title="Update" href="/developer/api-reference/messaging-api-v2/update/" />
  <LinkCard title="การอ้างอิง Payload" href="/developer/api-reference/messaging-api-v2/payload-reference/" />
  <LinkCard title="การอ้างอิง Email payload" href="/developer/api-reference/messaging-api-v2/email-payload-reference/" />
  <LinkCard title="SMTP gateway" href="/developer/api-reference/smtp-gateway/" />
  <LinkCard title="การย้ายจาก v1" href="/developer/api-reference/messaging-api-v2/migration-from-v1/" />
</CardGrid>