วิธีใช้งาน OpenAI API

คู่มือนี้พาคุณใช้งาน OpenAI Responses API แบบลงมือทำ: ส่งคำขอไปยัง POST /v1/responses, อ่านเอาต์พุตแบบซ้อนกัน, เปิดใช้เครื่องมือในตัว, รักษาสถานะการสนทนาข้าม request และตรวจสอบสัญญา API ด้วย Apidog Responses API คืออินเทอร์เฟซใหม่ของ OpenAI สำหรับสร้างเอาต์พุตจากโมเดล และ คู่มือ Responses อย่างเป็นทางการ อธิบายว่าเหตุใด OpenAI จึงแนะนำให้โปรเจกต์ใหม่ใช้ API นี้ หากคุณเคยทดสอบเอนด์พอยต์เดิมอยู่แล้ว คุณสามารถนำ workflow ส่วนใหญ่กลับมาใช้ซ้ำได้ คล้ายกับ คู่มือการทดสอบ ChatGPT API ของเรา

ลองใช้ Apidog วันนี้

สิ่งที่คุณต้องมีก่อน

ก่อนเริ่มเรียก POST /v1/responses ให้เตรียมสิ่งต่อไปนี้:

• OpenAI API key ที่เข้าถึงโมเดลที่ต้องการได้ เก็บไว้ใน environment variable ไม่ใส่ตรง ๆ ในคำสั่งหรือไฟล์ที่แชร์
• ชื่อโมเดลที่บัญชีของคุณเรียกใช้ได้ ตรวจสอบจากแดชบอร์ด OpenAI หรือทดลองเรียกเอนด์พอยต์แทนการฮาร์ดโค้ด
• เครื่องมือส่ง HTTP request และดู JSON response เช่น curl สำหรับทดสอบเร็ว ๆ และ Apidog สำหรับตรวจสอบ schema, assertion และ mock response

Responses API มีเอนด์พอยต์หลักคือ POST /v1/responses คุณส่ง model และ input แล้วจะได้ response object ที่อาจมีข้อความ, function call และผลลัพธ์จากเครื่องมือที่ OpenAI โฮสต์ เช่น web search หรือ file search

การเรียกครั้งเดียวอาจมีหลายขั้นตอน เช่น โมเดลตัดสินใจค้นเว็บ อ่านผลลัพธ์ แล้วจึงเขียนคำตอบ รายละเอียดแต่ละขั้นตอนจะอยู่ใน output

จุดต่างหลักจาก API แบบข้อความเดิมมี 2 อย่าง:

1. ใช้เครื่องมือในตัวฝั่งเซิร์ฟเวอร์ได้ ไม่ต้องสร้างระบบค้นหา ไฟล์ หรือ sandbox เองทั้งหมด
2. มี state โดยค่าเริ่มต้น ทุก response มี id และคุณส่ง id นั้นเป็น previous_response_id ใน request ถัดไปเพื่อสนทนาต่อได้

OpenAI อธิบาย Responses API ว่าเป็นวิวัฒนาการของ Chat Completions และแนะนำสำหรับโปรเจกต์ใหม่ โดยรวมบทเรียนจาก Assistants API beta ให้เหลือโมเดลการทำงานเดียว

ทำความเข้าใจว่าต่างจาก Chat Completions อย่างไร

ถ้าคุณเคยใช้ POST /v1/chat/completions ความต่างหลักคือรูปแบบ request/response และการจัดการ state

Chat Completions ใช้ messages array และคืนค่าใน choices คุณต้องส่งประวัติการสนทนาทั้งหมดซ้ำในการเรียกแต่ละครั้ง และต้องจัดการ tool execution เอง

Responses API ใช้ input ซึ่งเป็น string หรือรายการแบบระบุชนิด และคืนค่าใน output ซึ่งเป็นรายการแบบระบุชนิดเช่นกัน นอกจากนี้ยังจัดเก็บสถานะและเรียกใช้เครื่องมือที่โฮสต์โดย OpenAI ได้

ด้าน	Chat Completions	Responses API
เอนด์พอยต์	POST /v1/chat/completions	POST /v1/responses
เนื้อหาคำขอ	messages array	input + instructions
รูปแบบเอาต์พุต	choices[].message	output array ของรายการแบบระบุชนิด
สถานะการสนทนา	ต้องส่งประวัติทั้งหมดซ้ำ	ใช้ store + previous_response_id
เครื่องมือในตัว	ต้องสร้างเอง	web_search, file_search, code_interpreter และอื่น ๆ
สถานะผลิตภัณฑ์	ยังรองรับ ไม่มีประกาศเลิกใช้	แนะนำสำหรับโปรเจกต์ใหม่

Chat Completions ยังไม่หายไป OpenAI ระบุว่าจะยังรองรับต่อ และคุณสามารถย้าย workflow ทีละส่วนได้ ไม่จำเป็นต้องเขียนใหม่ทั้งหมดในครั้งเดียว

ส่วน Assistants API กำลังจะถูกเลิกใช้งาน: OpenAI เลิกใช้งานเมื่อวันที่ 26 สิงหาคม 2025 และมีกำหนดสิ้นสุดวันที่ 26 สิงหาคม 2026 ดังนั้นงาน agent ใหม่ควรเริ่มบน Responses API

เรียก Responses API ครั้งแรก

เริ่มด้วย request ขั้นต่ำนี้ เปลี่ยนชื่อโมเดลให้ตรงกับโมเดลที่บัญชีของคุณเข้าถึงได้ และเก็บ API key ไว้ใน environment variable:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "input": "Write one sentence describing what an API mock server does.",
    "instructions": "You are a concise technical writer. No marketing language.",
    "store": true
  }'

ฟิลด์สำคัญใน request นี้คือ:

• model: โมเดลที่ต้องการใช้
• input: prompt หรือข้อมูลที่ส่งให้โมเดล
• instructions: คำสั่งระดับระบบหรือแนวทางการตอบ
• store: ตั้งเป็น true เพื่อให้ OpenAI บันทึก response object และนำไปใช้สนทนาต่อได้

อ่าน response ที่ได้กลับมา

ตัวอย่าง response แบบตัดทอน:

{
  "id": "resp_abc123",
  "object": "response",
  "status": "completed",
  "model": "gpt-5.5",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "A mock server returns predefined API responses so clients can be developed and tested before the real backend exists."
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 28,
    "output_tokens": 24,
    "total_tokens": 52
  }
}

จุดที่ควรสังเกต:

• ข้อความอยู่ที่ output[0].content[0].text
• ไม่ได้อยู่ใน field ระดับบนสุด
• id ระดับบนสุดคือค่าที่ใช้ต่อกับ previous_response_id
• usage.total_tokens ใช้ดูปริมาณ token ของ request นั้น

SDK อย่างเป็นทางการอาจมี helper เช่น output_text เพื่อรวมข้อความให้เป็น string เดียว แต่ถ้าคุณเรียก HTTP API โดยตรง ให้ parse จาก path ที่ซ้อนอยู่ใน output

ตัวอย่างอ่านค่าด้วย jq:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "input": "Write one sentence describing what an API mock server does."
  }' | jq -r '.output[0].content[0].text'

เพิ่มเครื่องมือในตัว

Responses API สามารถให้ OpenAI เรียกใช้เครื่องมือบางอย่างให้คุณได้ โดยประกาศใน tools array แล้วให้โมเดลตัดสินใจเองว่าจะเรียกใช้เมื่อใด

ประเภทเครื่องมือในตัวที่กล่าวถึง ได้แก่:

• web_search สำหรับค้นหาอินเทอร์เน็ตแบบเรียลไทม์พร้อม citation (web_search_preview แบบเก่ายังใช้ได้กับ integration เดิม แต่ไม่มี control ใหม่)
• file_search สำหรับดึงข้อมูลจากไฟล์ที่คุณอัปโหลด
• code_interpreter สำหรับรันและวิเคราะห์โค้ดใน sandbox
• computer_use สำหรับควบคุมอินเทอร์เฟซคอมพิวเตอร์
• image_generation สำหรับสร้างภาพใน response

ตัวอย่างเปิดใช้ web search:

{
  "model": "gpt-5.5",
  "input": "What changed in the latest OpenAPI release? Cite sources.",
  "tools": [
    {
      "type": "web_search"
    }
  ]
}

เมื่อโมเดลใช้เครื่องมือ output จะมีรายการที่บันทึกขั้นตอน เช่น web_search_call และตามด้วย message สุดท้าย คุณจึงตรวจสอบได้ว่าโมเดลเรียกใช้เครื่องมือจริง ไม่ใช่แค่ตอบข้อความกลับมา

ตัวอย่าง assertion ที่ควรตรวจ:

{
  "expected_tool_call_type": "web_search_call"
}

path ที่ใช้ตรวจใน response คือรายการใดรายการหนึ่งใน output ที่มี:

{
  "type": "web_search_call"
}

สนทนาต่อข้าม request

Responses API ใช้ 2 parameter สำหรับ state:

• store: ควบคุมว่า OpenAI จะจัดเก็บ response object หรือไม่ ค่าเริ่มต้นเป็นจริง และเก็บไว้ 30 วันโดยค่าเริ่มต้น
• previous_response_id: ใช้เชื่อม request ใหม่กับ response เดิม

ตัวอย่าง request ถัดไป:

{
  "model": "gpt-5.5",
  "input": "Now rewrite that for a non-technical audience.",
  "previous_response_id": "resp_abc123"
}

คุณไม่ต้องส่งประวัติการสนทนาทั้งหมดซ้ำ เพราะ OpenAI ใช้ previous_response_id เพื่อผูกบริบทให้

ถ้าต้องการทำงานแบบ stateless หรือมีข้อกำหนดห้ามเก็บข้อมูล ให้ตั้งค่า:

{
  "store": false
}

แล้วจัดการบริบทเองในฝั่งแอป

สำหรับงาน voice และ low-latency realtime audio OpenAI ใช้พื้นผิว API คนละแบบ ดูเพิ่มเติมใน คู่มือ GPT realtime API ของเรา และถ้าคุณสร้าง agent หลายขั้นตอน รูปแบบโดยรวมจะสอดคล้องกับ OpenAI Agents SDK

วิธีทดสอบใน Apidog

Apidog เป็นแพลตฟอร์มสำหรับทดสอบ ออกแบบ และ mock API ไม่ใช่ OpenAI SDK ดังนั้น workflow คือ:

1. สร้าง HTTP request ไปที่ /v1/responses
2. ส่ง request พร้อม header และ body ที่ถูกต้อง
3. ดู JSON response จริง
4. เขียน assertion บน field ที่แอปของคุณต้องใช้
5. บันทึก response ที่เป็นตัวแทนไว้ใช้ mock สำหรับ dev/test

1. เก็บ API key ใน environment variable

ใน Apidog ให้สร้าง environment เช่น OpenAI Prod แล้วเพิ่มตัวแปร:

OPENAI_API_KEY=sk-...

จากนั้นสร้าง request ใหม่:

POST https://api.openai.com/v1/responses

เพิ่ม header:

Authorization: Bearer {{OPENAI_API_KEY}}
Content-Type: application/json

Apidog จะแทนค่าตัวแปรตอนส่ง request ทำให้ไม่ต้องใส่ secret ลงใน request ที่อาจถูกแชร์ในทีม

2. ใส่ JSON body

ใช้ body แบบนี้เป็น baseline:

{
  "model": "gpt-5.5",
  "input": "Write one sentence describing what an API mock server does.",
  "instructions": "You are a concise technical writer. No marketing language.",
  "store": true
}

กดส่ง แล้วตรวจ response ที่ได้ โดยเฉพาะ:

id
status
output
usage.total_tokens

3. ยืนยัน field ที่แอปต้องพึ่งพา

HTTP 200 ไม่ได้แปลว่า response มีรูปแบบตรงกับที่แอปคาดหวังเสมอ ให้เพิ่ม assertion เพื่อให้ regression fail ชัดเจน

ตัวอย่าง validation ที่ควรมี:

• status เท่ากับ completed
• output[0].content[0].text มีอยู่และไม่เป็นค่าว่าง
• usage.total_tokens มากกว่า 0
• เมื่อส่ง tools แล้ว ใน output มี item ที่ type เท่ากับ web_search_call

ตัวอย่างแนวคิด assertion:

status == "completed"
output[0].content[0].text exists
usage.total_tokens > 0
output[*].type contains "web_search_call"

เครื่องมือ assertion แบบ visual ของ Apidog ช่วยกำหนด JSON path เหล่านี้ได้โดยไม่ต้องเขียน test script เอง ดูแนวทางจัดโครงสร้างได้จาก เทมเพลตกรณีทดสอบ API

เมื่อบันทึก request ลง collection แล้ว คุณสามารถรันซ้ำใน CI เพื่อจับ breaking change ได้

4. Mock response สำหรับพัฒนาแบบออฟไลน์

การเรียก OpenAI มีค่าใช้จ่ายและต้องใช้ network ซึ่งไม่เหมาะกับทุกกรณี เช่น:

• สร้าง UI ที่อ่าน response object
• รัน test pipeline ที่ไม่ควรเรียก API แบบเสียเงิน
• ต้องการผลลัพธ์ deterministic
• ทำงาน offline

วิธีทำใน Apidog:

1. ส่ง request จริงไปยัง /v1/responses
2. บันทึก payload response ที่เป็นตัวแทน
3. สร้าง mock จาก payload นั้น
4. ชี้ frontend หรือ test client ไปที่ mock URL ของ Apidog
5. ใช้ JSON shape เดียวกับ production โดยไม่ใช้ token จริง

เมื่อ response shape ของเอนด์พอยต์จริงเปลี่ยน คุณอัปเดต mock เพียงจุดเดียว แทนที่จะไล่แก้ test หลายที่ อ่านแนวคิดเพิ่มเติมได้ใน คำอธิบาย API จำลอง

แนวทางที่ดีคือแยกการใช้งานเป็น 2 ชั้น:

• ใช้เอนด์พอยต์จริงเพื่อตรวจ contract กับ OpenAI
• ใช้ mock เพื่อพัฒนาและทดสอบแบบรวดเร็ว ควบคุมได้ และไม่พึ่ง network

ทั้งสองอย่างจัดการได้ในโปรเจกต์ Apidog เดียวกัน

คำถามที่พบบ่อย

Responses API จะมาแทนที่ Chat Completions หรือไม่?

ไม่ได้บังคับ OpenAI เรียก Responses ว่าเป็นวิวัฒนาการของ Chat Completions และแนะนำสำหรับโปรเจกต์ใหม่ แต่ Chat Completions ยังรองรับอยู่โดยไม่มีประกาศวันเลิกใช้งาน คุณสามารถย้าย workflow ทีละส่วนได้

ส่วน Assistants API เป็น API ที่กำลังจะเลิกใช้งาน โดยมีวันสิ้นสุดในปี 2026

ความแตกต่างระหว่าง store และ previous_response_id คืออะไร?

store ควบคุมว่า OpenAI จะบันทึก response object หรือไม่ ค่าเริ่มต้นเป็นจริงและเก็บไว้ 30 วันโดยค่าเริ่มต้น

previous_response_id ใช้เชื่อม request ใหม่กับ response ที่บันทึกไว้ เพื่อให้โมเดลสนทนาต่อฝั่งเซิร์ฟเวอร์

ใช้ร่วมกันเมื่อต้องการ thread แบบมี state และตั้ง store: false เมื่อต้องการควบคุม context เอง

โมเดลใดบ้างที่รองรับ Responses API?

โมเดลทั่วไปในปัจจุบันของ OpenAI ถูกออกแบบให้ทำงานกับ Responses API แต่ความพร้อมใช้งานขึ้นอยู่กับบัญชีและโมเดลที่คุณเลือก

แนวทางที่ปลอดภัยคือ:

1. ตรวจรายการโมเดลในแดชบอร์ด OpenAI
2. ส่ง request ทดสอบผ่าน Apidog หรือ curl
3. อ่านค่า model ใน response เพื่อยืนยันว่า key ของคุณเรียกใช้งานได้

ทดสอบเครื่องมือในตัวโดยไม่เขียนโค้ดได้ไหม?

ได้ เพิ่ม tools array ใน JSON body ผ่าน Apidog ส่ง request แล้วตรวจว่า item การเรียกเครื่องมือ เช่น web_search_call ปรากฏใน output

ตัวอย่าง body:

{
  "model": "gpt-5.5",
  "input": "Summarize the latest API design best practices and cite sources.",
  "tools": [
    {
      "type": "web_search"
    }
  ]
}

จากนั้น assert ว่า:

output[*].type contains "web_search_call"

การทดสอบนี้เป็นการตรวจพฤติกรรมผ่าน HTTP โดยตรง จึงไม่ต้องใช้ SDK สำหรับการสร้างชุดทดสอบ agent หรือ API ที่ใหญ่ขึ้น ดู วิธีสร้างชุดการทดสอบ API จาก OpenAPI specs

สรุป

Responses API รวมข้อความ เครื่องมือที่ OpenAI โฮสต์ และ state การสนทนาไว้ในเอนด์พอยต์เดียวคือ POST /v1/responses

workflow หลักคือ:

1. ส่ง model, input และ instructions
2. อ่านผลลัพธ์จาก output[0].content[0].text
3. เปิดใช้เครื่องมือผ่าน tools
4. ใช้ previous_response_id เพื่อสนทนาต่อ
5. เพิ่ม assertion เพื่อยืนยัน contract ของ response

เพราะ response shape ต่างจาก Chat Completions วิธีที่ปลอดภัยที่สุดคือทดสอบ contract จริง ไม่พึ่งความจำจาก API เดิม

ใน Apidog คุณสามารถสร้าง request, เก็บ key เป็น environment variable, assert field ที่ซ้อนอยู่ใน output และ mock response สำหรับงาน offline ได้ในโปรเจกต์เดียว ดาวน์โหลด Apidog แล้วชี้การทดสอบไปที่ /v1/responses เพื่อดูว่า integration ของคุณได้รับ JSON แบบใดจริง ๆ หรือเริ่มตั้งค่าทั้งหมดใน Apidog ได้โดยไม่ต้องเขียน test code แม้แต่บรรทัดเดียว