Skip to main content

Zapier → iGMS Booking Webhook → ChargeAutomation

Written by Cathy Yap
Updated today

1. Purpose

This page explains how to build a Zap that:

  1. Receives booking_data webhooks from iGMS

  2. Decides what happened to the booking (accepted / new / cancelled / declined)

  3. Calls ChargeAutomation to:

    • Cancel an existing booking

    • Update an existing booking

    • Create a new booking (using extra guest data from iGMS)

2. Prerequisites

Before you start, you need:

  • A Zapier account with access to:

    • Webhooks by Zapier

    • ChargeAutomation app (or the API endpoint + API key)

  • iGMS account with permission to configure webhooks and use the API

  • iGMS API access token (see: getting-token.html in iGMS docs)

  • ChargeAutomation API key (or credentials needed for their Zapier app)

3. High-level Flow

  1. Trigger – iGMS sends a booking_data webhook to Zapier.

  2. First split (Path A vs Path B)

    • Path A – Active Booking: if booking_status is accepted or new → continue.

    • Path B – Booking Cancelled: if booking_status is cancelled or declined → call ChargeAutomation Cancel Booking.

  3. Check if booking already exists in ChargeAutomation

4. Sample iGMS Webhook Payload

This is the body that Zapier receives in Step 1:

Key fields we use:

  • booking_status

  • reservation_code

  • booking_uid

  • guest_uid

  • number_of_guests

  • price.price_total, price.currency

  • local_checkin_dttm, local_checkout_dttm

  • property_uid / listing_uid as our property mapping

5. Zap Structure (Overview)

The Zap layout (matching the attached diagram):

  1. Trigger – Webhooks by Zapier: Catch Hook

  2. Action – Paths: Split into paths

    • Path A – Active booking (accepted / new)
      3. Paths – Path conditions (status accepted/new)
      4. Webhooks by Zapier – GET (ChargeAutomation: Get Booking)
      5. Paths – Split into paths based on GET result

      • Path C – Booking exists → Update
        6. Paths – Path conditions (booking found)
        7. ChargeAutomation – Update Booking

      • Path D – Booking missing → Create
        8. Paths – Path conditions (booking not found)
        9. Webhooks by Zapier – GET (iGMS: Get Guest)
        10. ChargeAutomation – Create New Booking

    • Path B – Booking Cancelled
      11. Paths – Path conditions (status cancelled/declined)
      12. ChargeAutomation – Cancel Booking

The steps below describe how to configure each piece.

6. Step-by-step Configuration

Step 1 – Trigger: Webhooks by Zapier (Catch Hook)

  1. Create a new Zap.

  2. Trigger app: Webhooks by Zapier

  3. Event: Catch Hook

  4. Zapier gives a Custom Webhook URL – copy this URL.

  5. In iGMS, configure the booking_data webhook to POST to this URL.

  6. In iGMS, trigger a test booking so Zapier receives a sample payload.

  7. In Zapier, Test Trigger and confirm you see the JSON similar to the example above.

Step 2 – Add “Paths” (Top-Level Split)

  1. After the trigger, click + and choose Paths.

  2. Create 2 paths:

    • Path A – Active Booking

    • Path B – Booking Cancelled

7. Path B – Cancelled / Declined Booking

This path handles bookings that should be cancelled in ChargeAutomation.

Step 11 – Path conditions (Path B)

Conditions:

  • Field: data[] booking_status (from Step 1)

  • Condition group:

    • booking_status (Text exactly matches) cancelled

    • OR booking_status (Text exactly matches) declined

So Path B runs only for cancelled or declined bookings.

Step 12 – ChargeAutomation: Cancel Booking

  1. Add action in Path B: ChargeAutomation (or Webhooks by Zapier if you call API directly).

  2. Event: Cancel Booking (or POST to cancellation endpoint).

  3. Map the booking identifier:

    • If ChargeAutomation uses reservation code:

      • Booking ID / External ID: data[] reservation_code from Step 1.

    • If it uses another ID, map accordingly (keep it consistent with what we send on create/update).

  4. Test the step with a cancelled booking to confirm the booking is cancelled in ChargeAutomation.

Once Path B is working, any cancelled or declined status from iGMS will immediately cancel the booking in ChargeAutomation.

8. Path A – New / Accepted Bookings

Path A is for active bookings that must exist in ChargeAutomation (create or update).

Step 3 – Path conditions (Path A)

Set conditions so Path A only runs when booking is active:

  • Field: data[] booking_status

  • Conditions:

    • booking_status (Text exactly matches) accepted

    • OR booking_status (Text exactly matches) new

All other statuses should be handled by Path B or ignored.

Step 4 – Get Booking from ChargeAutomation (Webhooks GET)

This step checks if the booking is already in ChargeAutomation.

  1. Add action: Webhooks by Zapier

  2. Event: GET

  3. URL:

    Where {{reservation_code}} is mapped from Step 1 → data[] reservation_code.

  4. Headers / Auth:

    • Add whatever header ChargeAutomation requires, for example:

      • Authorization: Bearer <YOUR_API_KEY>
        or

      • x-api-key: <YOUR_API_KEY>

    • Leave body empty (it’s a GET).

  5. Test this step with a reservation that exists and one that doesn’t, so you see the difference:

    • Existing booking → HTTP 200 with booking data

    • Missing booking → HTTP 404 or an error message

Step 5 – Second “Paths” – Exists vs Not Exists

Immediately after the GET step, add another Paths action to branch based on whether ChargeAutomation found a booking.

Create 2 paths:

  • Path C – Booking Exists (Update)

  • Path D – Booking Missing (Create)

9. Path C – Booking Exists → Update Booking

Step 6 – Path conditions (Path C)

Configure conditions using the output from Step 4:

Typical options (choose one depending on ChargeAutomation response):

  • If you get an HTTP status field (e.g. status_code):

    • Condition: status_code (Number exactly matches) 200

  • Or if the body contains an ID (e.g. body.id exists):

    • Condition: body id (Is present)

Step 7 – ChargeAutomation: Update Booking

  1. Add action: ChargeAutomation – Update Booking
    (or a Webhooks by Zapier PUT/POST to the appropriate endpoint.)

  2. Map fields from Step 1 (webhook) and Step 4 (existing booking) as needed, for example:

    • Booking ID / External ID:

      • Use data[] reservation_code or the ID returned by Step 4.

    • Check-in: data[] local_checkin_dttm

    • Check-out: data[] local_checkout_dttm

    • Number of guests: data[] number_of_guests

    • Total amount: data[] price.price_total

    • Currency: data[] price.currency

    • Property / Listing mapping: data[] property_uid or listing_uid

  3. Test with an existing booking and confirm values update correctly in ChargeAutomation.

10. Path D – Booking Missing → Create Booking

If Step 4 did not find a booking, we create a new one.

Step 8 – Path conditions (Path D)

Set the opposite condition of Path C, e.g.:

  • If you used status code:

    • Condition: status_code (Number does not exactly match) 200
      or status_code (Number exactly matches) 404

  • Or if body has an error flag like success = false.

Step 9 – Get Guest Details from iGMS (Webhooks GET)

We need guest information that is not included in the original payload.

  1. Add action: Webhooks by Zapier – GET

  2. URL:

    • YOUR_IGMS_ACCESS_TOKEN – your token from iGMS docs (getting-token.html).

    • {{guest_uid}} – map from Step 1 → data[] guest_uid.

  3. Test the step and confirm you receive guest details (name, email, phone, etc.).

You should now have two sources of data:

  • Booking data from Step 1

  • Guest details from Step 9

Step 10 – ChargeAutomation: Create New Booking

  1. Add action: ChargeAutomation – Create Booking
    (or Webhooks by Zapier POST to their “create booking” endpoint.)

  2. Build the request body using fields from Step 1 and Step 9, for example:

    Field names may differ depending on ChargeAutomation’s API / Zap template – use the closest equivalents and keep the reservation_code as the external reference.

  3. Test with a booking that does not yet exist in ChargeAutomation. Confirm that:

    • The booking is created correctly

    • The guest details match iGMS

11. Testing & Go-Live Checklist

Before enabling the Zap:

  1. Test each scenario:

    • New booking (should create in ChargeAutomation)

    • Accepted booking that already exists (should update)

    • Cancelled / declined booking (should cancel)

  2. Verify identifiers:

    • reservation_code (or chosen ID) is consistent across:

      • Create Booking

      • Update Booking

      • Cancel Booking

      • Lookup (GET /booking/[id])

  3. Check timezones:

    • Confirm local_checkin_dttm and local_checkout_dttm are interpreted correctly in ChargeAutomation.

  4. Turn the Zap ON once all tests pass.

Did this answer your question?