Instruction
Difficulty level:
Implementing the Google Calendar integration: test and production checklist
This article is the practical implementation guide for the Google Calendar integration, with a checklist for both a test environment and production. The same Google Cloud project, OAuth client and infrastructure apply to both; in test you want a throw-away environment in which you can freely create, change and delete appointments. The numbered steps below describe the order; then use the per-environment checklists.
Infrastructure requirements (push + polling)
- Public webhook endpoint: Google watch channels post to
{base_url}/api/rest/integrationcalendarwebhook/google. This endpoint must be publicly reachable from Google. On a local dev box this means a tunnel (ngrok / Cloudflare tunnel) or a publicly reachable test host; without a reachable endpoint Google cannot register a channel. - Channel lifecycle: a watch channel expires; cron auto-renews it once it is within 2 days of expiry.
- Cron + worker: the
ExecuteIntegrationscron must run for channel renewal and the polling fallback (> 30 min no sync). With queued processing a worker (RabbitMQ) must run for the inbound/renew jobs. Restart workers + clear OPcache after deploying worker/config changes.
Checklist — test environment
- ☐ Google Cloud project created/selected.
- ☐ Google Calendar API enabled.
- ☐ OAuth consent screen configured with scopes
calendar.readonly+calendar.events. - ☐ For an External app: the signing-in user added as a test user.
- ☐ OAuth client (Web application) created; Client ID + secret noted.
- ☐ Redirect URI
{base_url}/integrations/redirect/{int_id}registered in the OAuth client. - ☐ Dedicated Google account available to sign in with (not a personal account).
- ☐ Public webhook URL reachable by Google.
- ☐
ExecuteIntegrationscron running (renewal + polling fallback). - ☐ Worker (RabbitMQ) running if queued processing is used.
- ☐ Auth screen filled + Step 1 consent + Step 2 connect done.
- ☐ Object → calendar mapping filled (incl. any
*default). - ☐ Outbound and inbound fields set; integration active; watch channel created.
- ☐ End-to-end tested: booking status change → event in Google; and event in Google → booking in i-Reserve.
Checklist — production environment
- ☐ Production OAuth client with production redirect URI on the production base url; secret managed separately.
- ☐ OAuth consent screen published if needed (not in testing mode) so the refresh token does not expire prematurely.
- ☐ Webhook endpoint publicly reachable in production (real host/SSL, no tunnel).
- ☐
ExecuteIntegrationscron and worker(s) running in production; OPcache cleared after deploy. - ☐ Real object → calendar mapping (no test calendars/objects).
- ☐ First live sync verified + watch channel status checked on the diagnostics screen.
- ☐ Rollback known: setting the integration inactive stops sync without losing data.
Create or select a project in the Google Cloud Console and enable the Google Calendar API.
Configure the OAuth consent screen (Internal or External), add the scopes calendar.readonly and calendar.events, and for External add the signing-in user as a test user.
Create an OAuth client ID (Web application), register the redirect URI i-Reserve shows and note the Client ID and secret.
Ensure the webhook endpoint (.../integrationcalendarwebhook/google) is publicly reachable and that the ExecuteIntegrations cron and (if used) the RabbitMQ worker are running.
In i-Reserve fill the authentication screen (client/secret/return url), run consent + connect, fill the object-calendar mapping and the outbound/inbound fields.
Set the integration active, verify on the diagnostics screen that the watch channel was created, test inbound and outbound end-to-end and complete the per-environment checklist.
