ขีดจำกัดการใช้งาน

ตั้งแต่วันที่ 1 พฤษภาคม 2026 เป็นต้นไป เราได้อัปเดตโควต้าการใช้งานสำหรับ API นี้แล้ว โปรเจ็กต์ Google Cloud ที่ใช้ API นี้ระหว่างเดือนพฤศจิกายน 2025 ถึงเมษายน 2026 จะยังคงใช้โควต้าการใช้งานที่ตั้งไว้ก่อนหน้านี้ต่อไป โปรเจ็กต์ Cloud ที่สร้างขึ้นตั้งแต่วันที่ 1 พฤษภาคม 2026 เป็นต้นไปจะอยู่ภายใต้โควต้า API ใหม่

ดูข้อมูลเพิ่มเติม รวมถึงไทม์ไลน์ได้ที่โมเดลมาตรฐานของ Google Workspace สำหรับเครื่องมือและ API ของตัวแทน

ดูประกาศฉบับเต็มได้ที่เครื่องมือสำหรับตัวแทนและข้อมูลอัปเดตด้านความปลอดภัยสำหรับนักพัฒนาแอป Google Workspace

Google ปฏิทิน API มีโควต้าเพื่อให้มั่นใจว่าผู้ใช้ทุกคนจะใช้งานได้อย่างเท่าเทียมกัน ข้อจำกัดที่สำคัญ 3 ประการที่ควรพิจารณาเมื่อใช้ Calendar API มีดังนี้

• โควต้าการใช้งาน API: บังคับใช้ต่อโปรเจ็กต์และต่อผู้ใช้ ดูข้อมูลเพิ่มเติมได้ที่ประเภทโควต้าการใช้งาน Calendar API

• ขีดจำกัดการใช้งาน Google ปฏิทิน ทั่วไป: Google Calendar API เป็นบริการที่ใช้ร่วมกันซึ่งมีข้อจำกัดเพื่อปกป้องประสิทธิภาพโดยรวมของระบบ Google Workspace ดูข้อมูลเพิ่มเติมได้ที่หลีกเลี่ยง ขีดจำกัด การใช้ปฏิทิน

• ขีดจำกัดในการดำเนินการ: ขีดจำกัดเหล่านี้อาจถูกจำกัดได้ทุกเมื่อ เช่น หากคุณพยายามเขียนไปยังปฏิทินเดียวอย่างรวดเร็ว

โควต้า Calendar API

ระบบจะบังคับใช้โควต้า 2 ประเภท ได้แก่

• ต่อนาทีต่อโปรเจ็กต์: นี่คือจำนวนคำขอที่โปรเจ็กต์ Google Cloud ของคุณสร้างได้ใน 1 นาที

• ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์: นี่คือจำนวนคำขอที่ผู้ใช้รายใดรายหนึ่งสามารถส่งในโปรเจ็กต์ที่อยู่ในระบบคลาวด์ของคุณ ขีดจํากัดนี้มีจุดประสงค์เพื่อ ช่วยให้คุณมั่นใจได้ว่าการใช้งานจะกระจายอย่างเป็นธรรมในหมู่ผู้ใช้

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

ตารางต่อไปนี้แสดงรายละเอียดขีดจำกัดเหล่านี้

ประเภทขีดจำกัดการใช้งาน	ขีดจำกัด
ต่อนาทีต่อโปรเจ็กต์	คำขอ 10,000 รายการ
ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์	คำขอ 600 รายการ

เกณฑ์การเรียกเก็บเงินรายวัน

ขีดจำกัดต่อวันต่อโปรเจ็กต์นี้จะกำหนดจำนวนคำขอสูงสุดที่โปรเจ็กต์ Google Cloud ของคุณใช้ได้ภายในระยะเวลา 24 ชั่วโมงก่อนที่จะมีการเรียกเก็บเงิน

การใช้งานที่ต่ำกว่าเกณฑ์นี้จะไม่มีค่าใช้จ่ายเพิ่มเติมและระบบจะไม่เรียกเก็บเงินจากบัญชี Google Cloud ของคุณ เราจะแชร์รายละเอียดการเรียกเก็บเงินทั้งหมดในภายหลังในปี 2026 โดยจะแจ้งให้ทราบล่วงหน้าอย่างน้อย 90 วันก่อนที่การเปลี่ยนแปลงจะมีผล

คุณไม่สามารถขอเพิ่มขีดจำกัดเกณฑ์รายวันนี้ได้

ตารางต่อไปนี้แสดงรายละเอียดขีดจำกัด

ประเภทขีดจำกัดของเกณฑ์	ขีดจำกัด
ต่อวันต่อโปรเจ็กต์	คำขอ 1,000,000 รายการ

โปรดดูข้อมูลเพิ่มเติมที่โมเดลมาตรฐานของ Google Workspace สำหรับเครื่องมือและ API ของตัวแทน

แก้ไขข้อผิดพลาดเกี่ยวกับโควต้าตามเวลา

สำหรับข้อผิดพลาดทั้งหมดที่อิงตามเวลา (คำขอสูงสุด N รายการต่อ X นาที) เราขอแนะนำให้ โค้ดของคุณตรวจหาข้อยกเว้นและใช้Exponential Backoff ที่ถูกตัดเพื่อให้แน่ใจว่าอุปกรณ์ จะไม่สร้างภาระงานมากเกินไป

Exponential Backoff เป็นกลยุทธ์การจัดการข้อผิดพลาดมาตรฐานสำหรับแอปพลิเคชันเครือข่าย อัลกอริทึม Exponential Backoff จะส่งคำขออีกครั้งโดยใช้เวลารอที่เพิ่มขึ้นแบบเอ็กซ์โปเนนเชียล ระหว่างคำขอต่างๆ จนถึงเวลา Backoff สูงสุด หากคำขอไม่สำเร็จ คุณควร เพิ่มความล่าช้าระหว่างคำขอเมื่อเวลาผ่านไปจนกว่าคำขอจะสำเร็จ

ตัวอย่างอัลกอริทึม

อัลกอริทึม Exponential Backoff จะลองส่งคำขออีกครั้งแบบเอ็กซ์โปเนนเชียล โดยจะเพิ่มเวลารอ ระหว่างการลองส่งอีกครั้งจนถึงเวลา Backoff สูงสุด เช่น

1. ส่งคำขอไปยัง Google ปฏิทิน API
2. หากคำขอไม่สำเร็จ ให้รอ 1 + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
3. หากคำขอไม่สำเร็จ ให้รอ 2 + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
4. หากคำขอไม่สำเร็จ ให้รอ 4 + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
5. และอื่นๆ สูงสุด maximum_backoff ครั้ง
6. รอและลองอีกครั้งต่อไปจนกว่าจะถึงจำนวนครั้งสูงสุดที่ลองใหม่ได้ แต่ไม่ต้องเพิ่มระยะเวลารอ ระหว่างการลองใหม่

ที่ไหน

• เวลารอคือ min(((2^n)+random_number_milliseconds), maximum_backoff) โดย n จะเพิ่มขึ้น 1 สำหรับการวนซ้ำ (คำขอ) แต่ละครั้ง
• random_number_milliseconds คือจำนวนมิลลิวินาทีแบบสุ่มที่น้อยกว่าหรือเท่ากับ 1,000 ซึ่งจะช่วยหลีกเลี่ยงกรณีที่ไคลเอ็นต์จำนวนมากซิงค์กันใน บางสถานการณ์และทั้งหมดลองอีกครั้งพร้อมกัน ซึ่งจะส่งคำขอเป็นชุดที่ซิงค์กัน ระบบจะคำนวณค่าของ random_number_milliseconds ใหม่หลังจากคำขอ ลองอีกครั้งแต่ละครั้ง
• maximum_backoff โดยทั่วไปจะยาว 32 หรือ 64 วินาที ค่าที่เหมาะสม ขึ้นอยู่กับกรณีการใช้งาน

ไคลเอ็นต์จะลองอีกครั้งต่อไปได้หลังจากถึงเวลา maximum_backoff การลองใหม่หลังจากจุดนี้ไม่จำเป็นต้องเพิ่มเวลา Backoff ต่อไป ตัวอย่างเช่น หากไคลเอ็นต์ใช้ maximum_backoff เป็นเวลา 64 วินาที หลังจากถึงค่านี้แล้ว ไคลเอ็นต์จะลองอีกครั้งทุกๆ 64 วินาทีได้ ในบางกรณี ไม่ควรให้ไคลเอ็นต์ลองอีกครั้งอย่างไม่มีกำหนด

เวลาในการรอระหว่างการลองใหม่และจำนวนครั้งที่ลองใหม่จะขึ้นอยู่กับกรณีการใช้งาน และสภาพเครือข่าย

ราคา

การใช้ Google ปฏิทิน API แบบมาตรฐานทั้งหมดจะใช้งานได้โดยไม่มีค่าใช้จ่ายเพิ่มเติม การใช้เกินโควต้า ขีดจำกัดคำขอจะมีการเรียกเก็บเงินจากบัญชีสำหรับการเรียกเก็บเงินใน Google Cloud ในช่วงปลายปี 2026 ดูข้อมูลเพิ่มเติมได้ที่โมเดลมาตรฐานของ Google Workspace สำหรับเครื่องมือและ API ของตัวแทน

ขอเพิ่มโควต้า

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

โปรเจ็กต์แต่ละโปรเจ็กต์อาจมีโควต้าไม่เหมือนกัน เมื่อคุณใช้ Google Cloud มากขึ้นเรื่อยๆ ค่าโควต้าอาจต้องเพิ่มขึ้น หากคาดว่าการใช้งานจะเพิ่มขึ้นอย่างเห็นได้ชัดในอนาคต คุณสามารถขอปรับโควต้าล่วงหน้าได้จากหน้าโควต้าและขีดจำกัดของระบบในคอนโซล Google Cloud

ดูข้อมูลเพิ่มเติมได้ที่แหล่งข้อมูลต่อไปนี้

• เกี่ยวกับการปรับโควต้า
• ดูการใช้โควต้าและขีดจำกัด
• ขอเพิ่มขีดจำกัดโควต้า

แก้ปัญหา

หากใช้โควต้าใดโควต้าหนึ่งเกิน ระบบจะจำกัดอัตราการใช้งานของคุณและคุณจะได้รับรหัสสถานะ 403 usageLimits หรือรหัสสถานะ 429 usageLimits ในการตอบกลับคำค้นหา

หากเกิดกรณีนี้ขึ้น คุณสามารถลองทำดังนี้

1. โปรดปฏิบัติตามแนวทางปฏิบัติแนะนำทั้งหมด ได้แก่ ใช้การถอยแบบ ทวีคูณ สุ่มรูปแบบการเข้าชม และใช้การแจ้งเตือนแบบพุช

2. หากโปรเจ็กต์เติบโตขึ้นและมีผู้ใช้มากขึ้น คุณสามารถขอเพิ่มโควต้าได้

3. หากถึงขีดจำกัดโควต้าต่อผู้ใช้แล้ว คุณจะทำสิ่งต่อไปนี้ได้

   • หากใช้บัญชีบริการ ให้จัดสรรภาระงานให้กับผู้ใช้หรือแบ่งภาระงานระหว่างบัญชีบริการหลายบัญชี

   • แม้ว่าคุณจะขอเพิ่มโควต้าต่อผู้ใช้ได้ แต่โดยทั่วไปแล้ว เราไม่แนะนำให้เพิ่มโควต้าเกินค่าเริ่มต้น เนื่องจากแอปพลิเคชันของคุณอาจเริ่มใช้งานถึงขีดจำกัดประเภทอื่นๆ เช่น ขีดจำกัดการใช้งานปฏิทินทั่วไปหรือขีดจำกัดการดำเนินงาน

4. ทดสอบขีดจำกัดโควต้าโดยลงทะเบียนโปรเจ็กต์ทดสอบแยกต่างหากที่มี การกำหนดค่าคล้ายกับโปรเจ็กต์ที่ใช้งานจริง ดูข้อมูลเพิ่มเติมได้ที่การจัดการขีดจำกัดโควต้าทดสอบ

สุ่มรูปแบบการเข้าชม

ไคลเอ็นต์ปฏิทินมีแนวโน้มที่จะมีรูปแบบการเข้าชมที่ผันผวนเนื่องจาก ไคลเอ็นต์หลายรายดำเนินการพร้อมกัน ตัวอย่างเช่น แนวทางปฏิบัติที่ไม่ดีที่พบบ่อยสำหรับไคลเอ็นต์ปฏิทินคือการซิงค์แบบเต็มตอนเที่ยงคืน ซึ่งเกือบทั้งหมดจะทำให้คุณใช้โควต้าต่อนาทีเกิน และส่งผลให้มีการจำกัดอัตราคำขอและการหยุดชั่วคราว

โปรดกระจายการเข้าชมตลอดทั้งวันทุกที่ที่เป็นไปได้เพื่อหลีกเลี่ยงปัญหานี้ หากลูกค้าต้องซิงค์ทุกวัน ให้ลูกค้ากำหนดเวลาแบบสุ่ม (แตกต่างกันสำหรับลูกค้าแต่ละราย) หากต้องการดำเนินการเป็นประจำ ให้เปลี่ยนช่วงเวลา +/- 25% ซึ่งจะช่วยกระจายการเข้าชม ให้สม่ำเสมอมากขึ้นและมอบประสบการณ์การใช้งานที่ดียิ่งขึ้นให้แก่ผู้ใช้

ใช้ข้อความ Push

Use Case ทั่วไปคือการดำเนินการเมื่อใดก็ตามที่มีการเปลี่ยนแปลงในปฏิทินของผู้ใช้ รูปแบบที่ไม่ควรทำในที่นี้คือการสำรวจปฏิทินทุกรายการที่คุณสนใจซ้ำๆ ซึ่งจะทำให้โควต้าของคุณหมดลงอย่างรวดเร็ว ตัวอย่างเช่น หากแอปพลิเคชันมีผู้ใช้ 5,000 รายและสำรวจปฏิทินของผู้ใช้แต่ละรายทุกๆ 1 นาที คุณจะต้องมีโควต้าต่อนาทีอย่างน้อย 5,000 รายการ แม้ว่าจะยังไม่ได้ดำเนินการใดๆ ก็ตาม

แอปพลิเคชันฝั่งเซิร์ฟเวอร์สามารถลงทะเบียนรับข้อความ Push ได้ ซึ่งจะช่วยให้เรา แจ้งให้คุณทราบเมื่อมีสิ่งที่คุณสนใจเกิดขึ้น การตั้งค่าเหล่านี้ต้องใช้ความพยายามมากกว่า แต่จะช่วยให้คุณใช้โควต้าได้อย่างมีประสิทธิภาพมากขึ้นอย่างมาก และมอบประสบการณ์การใช้งานที่ดีขึ้น ตรวจสอบว่าคุณได้ระบุ eventType ที่ต้องการรับการแจ้งเตือน ดูข้อมูลเพิ่มเติมได้ที่การแจ้งเตือนแบบพุช

การจัดสรรที่เหมาะสมด้วยบัญชีบริการ

หากแอปพลิเคชันของคุณส่งคำขอโดยใช้การมอบสิทธิ์ระดับโดเมน ระบบจะเรียกเก็บเงินจากบัญชีบริการตามโควต้า "ต่อนาทีต่อผู้ใช้ต่อ โปรเจ็กต์" โดยค่าเริ่มต้น ไม่ใช่ผู้ใช้ที่คุณแอบอ้าง ซึ่งหมายความว่าบัญชีบริการมีแนวโน้มที่จะใช้โควต้าจนหมดและถูกจำกัดอัตรา แม้ว่าบัญชีบริการอาจทำงานในปฏิทินของผู้ใช้หลายรายก็ตาม

คุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยใช้quotaUserพารามิเตอร์ URL (หรือ x-goog-quota-userส่วนหัว HTTP) เพื่อระบุผู้ใช้ที่จะเรียกเก็บเงิน โดยจะใช้ สำหรับการคำนวณโควต้าเท่านั้น ดูข้อมูลเพิ่มเติมได้ที่การจำกัดคำขอต่อผู้ใช้

ทดสอบการจัดการขีดจำกัดโควต้า

เราขอแนะนำอย่างยิ่งให้ทดสอบสถานการณ์ในสภาพแวดล้อมจริงเพื่อให้แน่ใจว่าแอปพลิเคชันของคุณจะจัดการกับการเข้าถึงโควต้าได้อย่างราบรื่น ในทางปฏิบัติ (เช่น ผ่านการลองใหม่ด้วย การถอยแบบทวีคูณ) และเพื่อลดการรบกวนที่อาจเกิดขึ้นกับผู้ใช้

หากต้องการทดสอบโดยไม่รบกวนการใช้งานแอปพลิเคชันจริง เราขอแนะนำให้ ลงทะเบียนโปรเจ็กต์ทดสอบเท่านั้นแยกต่างหากในคอนโซล Google Cloud แล้วกำหนดค่าหน้าจอขอความยินยอม OAuth ในลักษณะที่คล้ายกับโปรเจ็กต์เวอร์ชันที่ใช้งานจริง จากนั้นคุณจะตั้งค่าขีดจำกัดโควต้าที่ต่ำเกินจริงสำหรับโปรเจ็กต์นี้และสังเกต ลักษณะการทำงานของแอปพลิเคชันได้

โควต้าเซิร์ฟเวอร์ MCP ของปฏิทิน

เซิร์ฟเวอร์ MCP ของปฏิทินใช้เมตริกการจัดสรรต้นทุนการค้นหา ตารางต่อไปนี้แสดงรายละเอียดค่าใช้จ่ายในการค้นหาสำหรับแต่ละวิธีของเซิร์ฟเวอร์ MCP ปฏิทิน ตามส่วนต่างๆ

โควต้า MCP ของปฏิทิน

ระบบจะบังคับใช้โควต้า 2 ประเภท ได้แก่

• ต่อนาทีต่อโปรเจ็กต์: นี่คือค่าใช้จ่ายในการค้นหาสำหรับโปรเจ็กต์ Google Cloud เป็นเวลา 1 นาที

• ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์: นี่คือค่าใช้จ่ายในการค้นหาสำหรับโปรเจ็กต์ Google Cloud ของคุณเป็นเวลา 1 นาทีที่ผู้ใช้รายใดรายหนึ่งใช้ได้

ตารางต่อไปนี้แสดงรายละเอียดโควต้าเหล่านี้

ประเภทขีดจำกัดการใช้งาน	ค่าใช้จ่ายในการค้นหา
ต่อนาทีต่อโปรเจ็กต์	10,000
ต่อนาทีต่อผู้ใช้ต่อโปรเจ็กต์	600

โควต้าชุดเครื่องมือ MCP ของปฏิทิน

ตารางต่อไปนี้แสดงรายละเอียดค่าใช้จ่ายในการค้นหาสำหรับcalendarmcp.googleapis.com ชุดเครื่องมือแต่ละชุด

ปลายทาง	เครื่องมือ	ค่าใช้จ่ายในการค้นหา
/mcp/v1	create_event	1
	delete_event	10
	get_event	1
	list_events	1
	respond_to_event	1
	search_events	1
	update_event	1
	suggest_time	1
	list_calendars	1

ดูข้อมูลเพิ่มเติมได้ที่ข้อมูลอ้างอิงเกี่ยวกับ Calendar MCP API

หัวข้อที่เกี่ยวข้อง

• ส่งคำขอแบบกลุ่ม
• เคล็ดลับด้านประสิทธิภาพ
• หลีกเลี่ยงขีดจำกัดการใช้ปฏิทิน