Google Calendar API 페이지네이션과 동기화

이 가이드에서 사용하는 명령어 레퍼런스: 페이지네이션된 일정 조회는 nylas calendar events list, 캘린더 목록 확인은 nylas calendar list, 헤드리스 설정은 nylas auth config, 이벤트 알림은 nylas webhook create, 스케줄링 워크플로우는 nylas calendar find-time를 참고하세요.

Google Calendar API의 nextPageToken과 maxResults는 어떻게 작동하나요?

Google Calendar API events.list에서 maxResults는 페이지 크기를 설정하고 nextPageToken은 다음 일정 페이지를 가리킵니다. 응답은 요청한 것보다 적은 일정을 포함하면서도 다음 토큰을 반환할 수 있으며, 특히 반복 일정, 삭제된 일정, 시간 범위 필터가 관련된 경우에 그렇습니다.

흔히 검색되는 google calendar api nextPageToken maxResults 질문에서 중요한 점은 페이지네이션이 한 번에 하나의 캘린더로 범위가 한정된다는 것입니다. 사용자에게 8개의 캘린더가 있다면, 동기화 코드는 하나의 전역 커서가 아니라 8개의 독립적인 페이지네이션 루프와 8개의 저장된 동기화 상태가 필요합니다.

Google Calendar API 페이지네이션은 어떻게 작동하나요?

Google Calendar API 페이지네이션은 일정 목록을 여러 HTTP 응답으로 나누며, 각 응답에는 호출자가 다음 페이지를 가져오기 위해 다시 전달하는 nextPageToken 문자열이 포함됩니다. events.list 엔드포인트는 /calendars/{calendarId}/events 아래에 있으므로 페이지네이션 상태는 캘린더별로 범위가 한정됩니다. 캘린더가 5개인 사용자는 5개의 독립적인 페이지네이션 커서를 갖게 됩니다.

Google Calendar API events.list 문서에 따르면 기본 페이지 크기는 250이고 요청당 최대 2,500개의 결과를 반환합니다 (Gmail messages.list의 상한인 500보다 5배 큼). 따라서 일정이 10,000개인 캘린더는 최대 페이지 크기로 최소 4번, 기본 크기로는 40번의 순차 API 호출이 필요합니다. 아래 루프는 단일 캘린더를 페이지네이션합니다:

from googleapiclient.discovery import build

service = build("calendar", "v3", credentials=creds)

all_events = []
page_token = None

while True:
    response = service.events().list(
        calendarId="primary",
        maxResults=2500,
        pageToken=page_token,
        singleEvents=True,
        orderBy="startTime",
    ).execute()

    all_events.extend(response.get("items", []))
    page_token = response.get("nextPageToken")

    if not page_token:
        break

print(f"Fetched {len(all_events)} events")

이 코드는 하나의 캘린더를 페이지네이션합니다. 사용자는 보통 기본 캘린더 외에 공유, 보조, 구독 캘린더를 가지고 있으므로, 프로덕션 동기화 클라이언트는 이 루프를 calendarList.list 결과를 순회하는 외부 루프로 감쌉니다.

Google Calendar API ETag If-Match 412 오류는 어디서 처리해야 하나요?

Google Calendar API의 ETag, If-Match, 412 Precondition Failed 오류는 페이지네이션 토큰 문제가 아니라 동시성 제어 문제입니다. 페이지네이션과 동기화 토큰 처리는 이 페이지에서 다루고, 오래된 일정 업데이트, events.patch, 낙관적 동시성에 대한 질문은 Google API 412 오류 해결 (ETag, If-Match)을 참고하세요.

Google Calendar 증분 동기화는 어떻게 작동하나요?

Google Calendar 증분 동기화는 마지막 페이지네이션 응답, 즉 nextPageToken이 없는 페이지에서만 반환되는 syncToken을 사용합니다. 이 토큰을 캘린더별로 저장합니다. 다음 동기화에서 이를 syncToken으로 events.list에 전달하면 응답에는 마지막 동기화 이후 생성, 수정, 삭제된 일정만 포함됩니다. Calendar API 동기화 가이드에 따르면 이것이 로컬 복사본을 최신 상태로 유지하는 권장 패턴입니다.

syncToken이 무효화되면 (보통 몇 주간의 비활성 후 또는 Google이 토큰을 회전할 때) events.list는 410 Gone을 반환합니다. Gmail의 유사한 실패는 대신 404를 반환합니다. 코드는 410을 잡아서 저장된 토큰을 폐기하고 처음부터 전체 페이지네이션을 다시 실행하여 새로운 syncToken을 얻어야 합니다. 코드 경로는 다음과 같습니다:

def incremental_sync(service, calendar_id, stored_token):
    """Sync changes since stored_token, or full-sync on 410."""
    try:
        response = service.events().list(
            calendarId=calendar_id,
            syncToken=stored_token,
        ).execute()
        return response.get("items", []), response.get("nextSyncToken")
    except HttpError as e:
        if e.resp.status == 410:
            # Token invalidated — full re-paginate
            return full_paginate(service, calendar_id)
        raise

한 가지 더 미묘한 점이 있습니다. syncToken 요청은 초기 페이지네이션에서 작동하는 대부분의 필터 파라미터를 사용할 수 없으며, 여기에는 q (텍스트 검색), timeMin, timeMax, singleEvents가 포함됩니다. singleEvents=True로 동기화를 초기화했다면 이후의 모든 증분 호출에서도 이를 생략해야 하며, 그렇지 않으면 API가 400 Bad Request를 반환합니다.

반복 일정은 왜 페이지네이션 문제가 되나요?

Google Calendar는 주간 스탠드업이나 월간 전체 회의를 각 발생마다 별도의 일정이 아니라 반복 규칙 (RFC 5545에 따른 RRULE)이 있는 하나의 일정으로 표현합니다. events.list 엔드포인트는 singleEvents 파라미터에 따라 다르게 동작합니다. singleEvents=False (기본값)이면 응답에 반복 일정이 마스터 레코드로만 포함됩니다. 스탠드업에 대해 항목 하나를 받고 클라이언트 측에서 직접 확장해야 합니다. singleEvents=True이면 API가 모든 반복을 개별 인스턴스로 확장하며 응답이 10-100배 커질 수 있습니다.

90일 범위에서 매일 반복되는 마스터 이벤트 500개를 확장하면 45,000개의 인스턴스가 생성됩니다. singleEvents 없이 같은 쿼리를 실행하면 500개의 행이 반환됩니다. 둘 다 정당한 사용 사례가 있지만 (분석에는 마스터 이벤트, 대시보드에는 인스턴스가 필요), 이 계약은 페이지네이션 비용이 확장되는 방식을 바꿉니다. timeMin과 timeMax를 설정하면 확장 범위가 제한되며, 종료일이 없는 반복이 있는 캘린더에서 singleEvents=True를 사용할 때 필수입니다.

직접 페이지네이션을 구현하면 무엇이 잘못되나요?

프로덕션급 Google Calendar 동기화 클라이언트를 구축하는 것은 캘린더별 페이지네이션 모델과 반복 일정 확장 때문에 Gmail보다 더 복잡합니다. 25줄짜리 루프로 시작한 코드는 모든 필수 케이스를 처리하고 나면 150-200줄로 늘어납니다:

• 캘린더당 하나의 동기화 커서 — 8개의 캘린더를 연결한 사용자는 8개의 저장된 syncToken 값, 8개의 전체 동기화 폴백 경로, 8세트의 상태 추적 메타데이터가 필요합니다.
• 410 Gone 폴백 — 모든 증분 호출에는 410을 감싸는 try/except와 다른 캘린더를 건드리지 않고 하나의 캘린더만 재설정하는 재페이지네이션 코드 경로가 필요합니다. 두 코드 경로 모두 올바르게 작동해야 합니다.
• OAuth2 토큰 수명 주기 — Google Calendar 액세스 토큰은 3,600초마다 만료됩니다. 동기화 루프에는 갱신 토큰 콜백, 만료된 토큰에 대한 재시도 로직, 갱신 토큰 자체를 위한 영구 저장소가 필요합니다.
• 반복 일정 시맨틱 — 분석 파이프라인에는 마스터 이벤트가, 대시보드 UI에는 확장된 인스턴스가 필요하며, 초기 동기화와 증분 동기화 사이에서 singleEvents가 한 번이라도 불일치하면 400 Bad Request가 반환됩니다.
• 속도 제한 — Google Calendar API는 사용자당 분당 600개, 프로젝트당 하루 1,000,000개의 쿼리를 제한합니다. 단순한 캘린더별 동기화 루프는 전역 제한보다 사용자별 제한에 먼저 도달하며, 반복 일정을 확장할 때 특히 그렇습니다.
• OAuth 동의 화면 — 코드를 실행하기 전에 Google Cloud 프로젝트, console.cloud.google.com에서 구성한 OAuth 동의 화면, 클라이언트 ID와 시크릿, calendar 또는 calendar.readonly 스코프, 리디렉션 URI가 필요합니다. 웹 양식을 클릭하는 데 15-20분이 걸립니다.

명령 하나로 Google Calendar 일정을 조회하려면?

Nylas CLI는 전체 페이지네이션, 동기화, OAuth 스택을 터미널 명령 하나로 대체합니다. Calendar API 방식이 150-200줄의 Python과 Google Cloud 프로젝트를 요구하는 곳에서, CLI는 한 줄과 2분짜리 설치로 줄입니다.

아래 세 가지 명령은 가장 일반적인 패턴을 다룹니다: 다가오는 일정 조회, 날짜 범위 지정, 단일 일정 읽기. 각각은 내부적으로 하나의 API 호출을 실행하며 CLI가 공급자 응답 간 페이지네이션을 처리합니다:

# List the next 50 upcoming events on the primary calendar
nylas calendar events list --limit 50 --json

# Events in the next 7 days
nylas calendar events list --days 7 --json

# Read one event by ID
nylas calendar events show <event-id> --json

모든 플래그는 nylas calendar events list, nylas calendar events show, 그리고 전체 명령어 레퍼런스를 참고하세요. 처음 사용하시나요? 시작하기 가이드부터 보세요.

일정을 페이지네이션하기 전에 모든 캘린더를 나열하려면?

일반적인 Google Workspace 사용자는 4-8개의 캘린더를 가지고 있습니다: 기본 캘린더, 1-3개의 공유 팀 캘린더, 선택적 보조 개인 캘린더, 1-2개의 구독 캘린더 (미국 공휴일, 스포츠 일정, 연락처 생일). 각각이 별도의 페이지네이션 범위입니다. Calendar API에서는 먼저 calendarList.list를 호출하여 접근 가능한 캘린더를 열거한 다음, 각 calendarId에 대해 events.list를 반복해야 하므로 요청 수와 저장된 동기화 상태가 N배로 늘어납니다.

CLI는 그 열거에 nylas calendar list를 사용합니다. nylas calendar events list --calendar-id와 결합하면 셸 스크립트 하나로 모든 캘린더를 페이지네이션할 수 있습니다:

# List every calendar the user has access to
nylas calendar list --json

# Loop pagination across all calendars
for cal in $(nylas calendar list --json | jq -r '.[].id'); do
  nylas calendar events list \
    --calendar-id "$cal" \
    --days 30 \
    --json
done

여러 계정에 걸쳐 페이지네이션하려면?

프로덕션 캘린더 워크플로우는 종종 여러 개의 연결된 Google 계정에 걸쳐 있습니다. 업무용과 개인 캘린더를 통합하는 임원, 5개 고객 계정에 걸쳐 일정을 잡는 어시스턴트, 워크스페이스의 모든 영업 담당자 캘린더를 읽는 세일즈 운영 도구가 그 예입니다. Google Calendar는 OAuth grant별로 할당량을 적용하므로 10개 계정을 병렬로 동기화해도 계정 간 스로틀링 없이 작동하지만, 애플리케이션 코드는 10세트의 갱신 토큰, 10개의 캘린더별 syncToken 번들, 10개의 활성 grant 상태를 추적해야 합니다.

CLI에서 grant는 일급 객체입니다. nylas auth list는 연결된 모든 계정을 보여줍니다. nylas auth whoami는 다음 명령이 사용할 grant를 출력합니다. nylas auth switch는 활성 grant를 변경합니다. 모든 캘린더 명령은 grant ID를 위치 인자로 받으므로 셸 스크립트 하나가 활성 상태를 변경하지 않고 grant들을 순회할 수 있습니다.

# Show every connected Google grant
nylas auth list --provider google --json

# Pull today's events from every connected calendar account
for grant in $(nylas auth list --provider google --json | jq -r '.[].id'); do
  nylas calendar events list "$grant" \
    --days 1 \
    --json
done

CI, cron 작업, 헤드리스 환경에서 동기화하려면?

Google Calendar OAuth2 액세스 토큰은 3,600초마다 만료되며, 브라우저 기반 갱신 흐름은 CI, Docker, AI 에이전트 샌드박스 등 무인 환경에서는 작동하지 않습니다. Google의 오프라인 액세스 흐름은 갱신 토큰을 얻기 위한 일회성 대화형 설정이 필요하고, 애플리케이션은 이를 시크릿 매니저에 저장하여 재동의 전까지 다음 6개월간 재사용합니다. 대안인 서비스 계정은 Google Workspace 도메인 전체 위임이 필요한데, 이는 관리자 전용 기능으로 일반 소비자 Google 계정에서는 사용할 수 없습니다.

Nylas CLI는 API 키 인증으로 브라우저를 우회합니다. nylas auth config --api-key는 브라우저를 거치지 않고 키를 저장합니다. nylas auth token은 다운스트림 API 호출을 위한 범위가 지정된 베어러 토큰을 생성합니다. nylas auth status는 현재 인증 상태를 보고하며, 컨테이너화된 배포의 헬스 체크에 유용합니다.

# Generate a daily schedule digest in a cron job — no browser
export NYLAS_API_KEY="nyk_..."
nylas auth config --api-key "$NYLAS_API_KEY"
nylas calendar events list --days 1 --json > /var/log/agenda.json

폴링 대신 웹훅을 사용해야 할 때는?

Google Calendar를 5분마다 폴링하면 계정당 하루 288번의 API 호출이 발생합니다. 연결된 사용자가 1,000명이면 하루 288,000번의 호출이며 대부분은 변경 사항이 없는 응답입니다. Google Calendar는 Cloud Pub/Sub 또는 웹훅 콜백 URL을 통한 푸시 알림 대안을 제공하지만, 설정에는 Pub/Sub 토픽, calendar-api-push@system.gserviceaccount.com에 대한 IAM 바인딩, 각 캘린더에 대한 감시 채널, 그리고 Google이 7일마다 감시를 만료시키므로 갱신 작업이 필요합니다.

CLI의 웹훅은 Pub/Sub 토픽 없이 등록됩니다. nylas webhook create는 HTTPS 엔드포인트와 트리거 목록을 등록합니다. nylas webhook list는 등록된 항목을 보여줍니다. nylas webhook triggers는 event.created, event.updated, event.deleted, calendar.created를 포함한 지원되는 모든 이벤트를 나열합니다. nylas webhook test send는 엔드포인트에 샘플 페이로드를 발사하여 수신기를 검증할 수 있게 합니다. nylas webhook verify는 수신 페이로드의 HMAC 서명을 검증합니다.

# Register a webhook for calendar event changes
nylas webhook create \
  --url https://example.com/hooks/calendar \
  --triggers event.created,event.updated,event.deleted \
  --json

# Verify an inbound payload signature
nylas webhook verify \
  --payload-file ./incoming.json \
  --signature "$X_NYLAS_SIGNATURE" \
  --secret "$WEBHOOK_SECRET"

일반적인 캘린더 사용에서 웹훅 이벤트 볼륨은 사용자당 하루 평균 5-20개로, 288번의 폴링 호출과 비교됩니다. 일정 변경과 애플리케이션이 이를 인지하는 사이의 지연 시간은 최대 5분에서 약 1초로 줄어듭니다.

다른 캘린더 공급자는 페이지네이션을 어떻게 처리하나요?

페이지네이션 계약을 가진 공급자는 Google Calendar만이 아닙니다. Microsoft Graph (Outlook 및 Exchange Online 캘린더)는 클라이언트가 그대로 따라가는 전체 URL인 @odata.nextLink와 증분 동기화를 위한 델타 링크 메커니즘을 사용합니다. CalDAV (iCloud, Yahoo, 호스팅된 Apple)는 REST 의미의 페이지네이션을 하지 않습니다. calendar-query 필터가 있는 REPORT 쿼리가 일치하는 일정을 단일 응답으로 반환하며, 동기화는 sync-collection과 ETag로 처리됩니다. Exchange Web Services (EWS, 구형 Exchange Server 배포에서 사용)는 IndexedPageItemView와 함께 FindItem을 사용합니다.

공급자별 가이드는 각 계약에서 동일한 문제를 다룹니다: 터미널에서 Google Calendar 관리하기, Outlook 캘린더 관리하기, Exchange 캘린더 관리하기, iCloud 캘린더 관리하기, Yahoo 캘린더 관리하기. 동일한 nylas calendar events list 명령이 모든 공급자에서 동일한 플래그로 실행되도록 문서화되어 있습니다.

위에 설명한 Outlook, Exchange, iCloud, Yahoo의 공급자 측 동작은 각 공급자의 공개 문서에서 가져온 것이며, 모든 백엔드에서 종단 간 실행으로 검증한 것은 아닙니다. 공급자별 워크플로우를 배포하기 전에 로컬에서 테스트하세요.

Google Calendar 동기화에는 시간이 얼마나 걸리나요?

일정이 500개인 단일 Google Calendar는 CLI 명령 하나로 약 2초 만에 동기화되고, 확장된 일정이 50,000개인 다중 캘린더 계정은 약 1분이 걸립니다. 같은 작업을 백오프가 있는 순차 Python 페이지네이션 루프로 처리하면 각각 약 4초와 약 6분이 걸리는데, 루프는 명시적인 스레드 풀 없이는 사용자당 분당 600 쿼리 상한까지 분산할 수 없기 때문입니다. 아래 벤치마크는 Google 서버까지 중간값 약 150ms 지연의 가정용 광대역 연결에서 측정했습니다.

실제 소요 시간 차이는 대부분 동시성에서 나옵니다. Python의 단순 순차 루프는 캘린더를 하나씩 순회하지만, CLI는 사용자당 분당 600 쿼리 상한까지 캘린더별 페이지네이션을 병렬로 분산합니다. 위의 API 호출 수는 동일합니다. CLI가 Google의 기본 호출을 더 저렴하게 만들 수는 없고, 더 빠르게 발송할 수 있을 뿐입니다.

일반적인 Google Calendar 동기화 레시피는?

캘린더 페이지네이션을 표준 UNIX 도구와 결합한 4가지 셸 패턴입니다. 각각 JSON 출력 파싱에 jq를, 기계가 읽을 수 있는 형식에 --json을 사용합니다.

오늘의 일정표

일일 일정표 스크립트는 nylas calendar events list --days 1을 jq 필터로 감싸 다음 24시간 동안의 모든 일정에 대해 시작 시간과 제목을 출력합니다. 셸 인사말 프롬프트, 터미널 대시보드, 아침 요약을 위해 LLM으로 파이프하는 데 유용합니다. 평균적인 계정에서 약 2초 만에 실행됩니다.

nylas calendar events list --days 1 --json \
  | jq -r '.[] | "\(.when.start_time) - \(.title)"'

여러 캘린더에 걸쳐 빈 시간 찾기

nylas calendar find-time은 모든 참가자의 빈/바쁨 데이터를 쿼리하여 요청한 시간 동안 모두가 비어 있는 슬롯을 반환합니다. CLI가 참석자 간 시간대 정규화를 처리하므로, 오전 9시 PT로 제안된 30분 슬롯은 응답에서 오후 12시 ET로도 읽힙니다. 원시 바쁨 시간대가 필요하면 nylas calendar availability check와 함께 사용하세요.

nylas calendar find-time \
  --participants you@example.com,colleague@example.com \
  --duration 30 \
  --days 7 \
  --json

이번 주 캘린더에서 충돌 감지하기

nylas calendar ai conflicts는 다음 N일을 스캔하여 세 가지 심각도 수준을 표시합니다: 하드 충돌 (동시 일정), 소프트 충돌 (회의 사이 15분 미만), 이동 시간 위험. 기본 조회 범위는 7일입니다. 각 충돌에 대한 해결안을 제안하려면 nylas calendar ai reschedule과 함께 사용하세요.

nylas calendar ai conflicts --days 7 --json

특정 주최자의 일정 일괄 거절하기

nylas calendar events list와 nylas calendar events rsvp를 결합하면 한 발신자의 모든 초대를 하나의 파이프라인으로 거절할 수 있습니다. RSVP 명령은 --status yes, --status no, --status maybe를 받습니다. 자신이 소유한 일정이라면 nylas calendar events delete로 대체하세요. 받은편지함 스타일의 분석은 nylas calendar analyze를 참고하세요.

nylas calendar events list --json \
  | jq -r '.[] | select(.organizer.email == "noisy@example.com") | .id' \
  | xargs -I{} nylas calendar events rsvp --id {} --status no

CLI 동기화는 원시 API 페이지네이션과 어떻게 비교되나요?

아래 표는 Google Calendar API Python 방식과 Nylas CLI를 9가지 역량에 걸쳐 비교합니다. 가장 큰 차이는 캘린더별 동기화 상태입니다. 캘린더 동기화 클라이언트는 사용자가 소유한 모든 캘린더에 대해 하나의 커서와 하나의 폴백 경로를 관리해야 하지만, CLI는 그 분산을 내부적으로 처리합니다.

개발자가 배포 전에 알아야 할 것은?

Google Calendar API의 nextPageToken이란 무엇인가요?

캘린더에서 events.list를 호출하면 API는 페이지당 최대 2,500개의 일정을 반환합니다 (기본값 250). 더 많은 일정이 있으면 응답에 nextPageToken 문자열이 포함됩니다. 그 토큰을 다음 요청의 pageToken 파라미터로 전달하여 다음 페이지를 가져옵니다. 응답에 nextPageToken이 더 이상 포함되지 않을 때까지 반복하며, 이는 끝에 도달했다는 의미이고 응답에는 증분 동기화를 위한 nextSyncToken이 포함됩니다.

syncToken을 사용한 Google Calendar 증분 동기화는 어떻게 작동하나요?

캘린더를 완전히 페이지네이션한 후 마지막 응답에 nextSyncToken이 포함됩니다. 이를 캘린더별로 저장하세요. 다음 동기화에서 이를 syncToken으로 events.list에 전달하면 응답에는 마지막 동기화 이후 생성, 수정, 삭제된 일정만 포함됩니다. 토큰이 무효화되었으면 API가 410 Gone을 반환하며, 새 토큰을 얻으려면 처음부터 전체 페이지네이션을 다시 실행해야 합니다.

Calendar API는 왜 404가 아니라 410을 반환하나요?

410 Gone은 리소스 (이 경우 토큰으로 식별되는 동기화 세션)가 존재했지만 의도적으로 무효화되었음을 클라이언트에 알립니다. 오래된 historyId에 대한 Gmail의 유사한 실패는 404를 반환하는데, Gmail의 히스토리 레코드는 롤링 윈도우로 만료되기 때문입니다. Calendar는 토큰 자체가 폐기되었기 때문에 410을 사용합니다. 기능적으로 둘 다 같은 의미입니다: 저장된 토큰을 폐기하고 완전히 재페이지네이션하세요.

Google Cloud 설정 없이 Calendar 일정을 조회할 수 있나요?

네. Nylas CLI는 OAuth2와 공급자 인증을 내부적으로 처리합니다. nylas calendar events list --limit 50 --json을 실행하면 Google Cloud 프로젝트 생성, OAuth 동의 화면 구성, 액세스 토큰 관리 없이 일정을 조회할 수 있습니다. 동일한 흐름이 Google, Outlook, Exchange, iCloud, Yahoo에서 작동합니다.

특정 캘린더 하나만 동기화하려면 어떻게 하나요?

nylas calendar events list에 --calendar-id를 전달하세요. 연결된 계정의 모든 캘린더 ID는 nylas calendar list로 확인할 수 있습니다. 캘린더 ID는 primary, en.usa#holiday@group.v.calendar.google.com, 또는 공유 캘린더의 경우 UUID 형태입니다.

반복 일정은 어떻게 처리하나요?

CLI는 기본적으로 반복 일정을 확장합니다. 12개월 동안의 주간 스탠드업은 각각 고유한 발생 시간을 가진 52개의 개별 행으로 표시됩니다. 기본 Google Calendar events.list 호출이 singleEvents=true를 사용하므로 소비자는 RRULE 구문을 해석할 필요 없이 확장된 인스턴스를 받습니다. 반복 규칙이 그대로 있는 마스터 이벤트는 현재 CLI 표면을 통해 노출되지 않습니다.

OAuth 팝업 없이 cron 작업에서 캘린더를 동기화할 수 있나요?

네. nylas auth login 대신 nylas auth config --api-key를 사용하세요. API 키 흐름은 브라우저를 열지 않으므로 헤드리스 머신, Docker 컨테이너, CI 파이프라인에서 실행됩니다. cron이 실행되는 곳에 키를 시크릿으로 저장하세요.

CLI는 Outlook과 iCloud 캘린더에서도 동일하게 작동하나요?

네. nylas calendar events list, nylas calendar events show, nylas calendar events create는 Google Calendar, Microsoft Graph (Outlook 및 Exchange Online), CalDAV (iCloud, Yahoo), EWS (구형 Exchange)에서 작동합니다. 공급자별 안내는 Outlook 캘린더 관리하기, iCloud 캘린더 관리하기, Exchange 캘린더 관리하기에 있습니다.

캘린더 변경에 대한 푸시 알림을 받을 수 있나요?

네. nylas webhook create는 Cloud Pub/Sub 토픽 없이 event.created, event.updated, event.deleted 같은 이벤트에 대한 HTTPS 엔드포인트를 등록합니다. 지원되는 모든 이벤트 유형은 nylas webhook triggers로 확인하세요.

다음 단계

캘린더 페이지네이션은 반복적으로 나타나는 여러 API 통합 과제 중 하나입니다. 아래 관련 가이드는 Gmail 동기화, ETag 기반 동시성 제어, 공급자별 캘린더 관리, 전체 명령 표면을 포함한 인접 워크플로우를 다룹니다.

• Gmail API 페이지네이션과 동기화 — 동일한 패턴을 messages.list와 historyId에 적용
• 터미널에서 Google Calendar 관리하기 — 생성, 수정, RSVP, 빈/바쁨 워크플로우
• 터미널에서 Outlook 캘린더 관리하기 — Microsoft Graph @odata.nextLink 대응 가이드
• 터미널에서 iCloud 캘린더 관리하기 — 동일한 명령으로 CalDAV 페이지네이션
• Gmail API If-Match 및 ETag 처리 — 412 Precondition Failed와 동시성 제어
• Google Calendar 소유권 변경 — 캘린더가 계정 간에 이전될 때
• 터미널에서 캘린더 관리하기 — 멀티 공급자 허브 가이드
• 시작하기 — 설치 방법과 최초 인증
• calendar events list 명령 — --limit, --days, 캘린더 선택, JSON 출력에 대한 정확한 플래그
• calendar list 명령 — 일정 페이지를 순회하기 전에 캘린더 열거
• 전체 명령어 레퍼런스 — 모든 플래그와 하위 명령어 문서