Incorrect deleting.

[salihj09-art]

Hey, I am facing some issues when deleting a seat, I am integrating the "cancel a booking" api documentation in make.com, the module is not deleting the correct booking from the cal.com calendar of the event-type. Example, if I have a booking for tomorrow at 15:00 and a booking for after tomorrow also at 15:00, and I request to cancel the one for after tomorrow, it just cancels the previous one (the one for tomorrow)

here is the module that gets the upcoming appointments

and here is the module that is supposed to delete the required seat or appointment

[dosubot[bot]]

Hi @salihj09-art! I'm Dosu and I’m helping the cal.com team.

The Cal.com API requires a unique booking ID to cancel a specific booking—using only the time or non-unique fields can result in deleting the wrong one if there are multiple bookings at the same time on different days. In Make.com, make sure you are passing the correct booking ID (not just the time or seatUid) from your "get upcoming appointments" module to the "cancel booking" module. Double-check that your mapping logic selects the intended booking by matching both the date/time and the unique ID, not just the first result in the list. This will ensure the correct booking is deleted every time. You can find more details in the API docs and codebase here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[salihj09-art]

I have the UID in the URL and the seatUid I the request content, what other unique IDs should I include and where.

@dosu

[dosubot[bot]]

You only need the bookingUid in the URL and the seatUid in the request body to cancel a specific seat—no other unique IDs are required for this operation. The API expects the URL like /v2/bookings/:bookingUid/cancel and the body as { "seatUid": "..." } for seat-level cancellation. If you want to cancel the entire booking as the host, use the bookingUid in the URL and put { "cancellationReason": "..." } in the body instead (no seatUid needed) — but for your use case, bookingUid and seatUid are enough. Make sure the seatUid you send actually belongs to the bookingUid you’re targeting, or the API will throw an error. More details here: API controller docs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[salihj09-art]

That is exactly what I have in the module, the bookingUid in the URL and the seated in the request.

@dosu

[dosubot[bot]]

The API will only cancel the seat if the bookingUid in the URL and seatUid in the body match exactly, and it validates this strictly before proceeding — so if the wrong booking is being cancelled, it's almost certainly a mapping issue in Make.com. Double-check that the bookingUid and seatUid you send actually belong to the intended booking and seat for the correct date/time.

Try adding a step in Make.com to log or output the bookingUid and seatUid right before the cancellation call, and compare them to the details of the booking you want to cancel. If your mapping is selecting the first result in a list, or not filtering by both date and UID, it could target the wrong booking. Filtering by both date/time and UID in your scenario should help ensure the right booking is cancelled.

If you can share a sample of the mapped data or payload, I can help pinpoint where the mapping might be going wrong.

For reference, the API logic and validation are described here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[salihj09-art]

this is the output that I get for the upcoming appointments, its all correct, but I requested the delete of slot number 2 not number 1 (the one with the name "jay), it deleted the number 1.

here is the module that deletes, it shows that the variable contains the correct UId, but strangely the output of this module shows the incorrect UId (the one from the time slot number 1) shown in the following screenshot:

I hardcoded the variable that is shown in the variable, it turned out correct

@dosu

[salihj09-art]

check the previous message. @dosu

…

On Thu, Aug 14, 2025 at 7:32 PM dosubot[bot] ***@***.***> wrote: The API will only cancel the seat if the bookingUid in the URL and seatUid in the body match exactly, and it validates this strictly before proceeding — so if the wrong booking is being cancelled, it's almost certainly a mapping issue in Make.com. Double-check that the bookingUid and seatUid you send actually belong to the intended booking and seat for the correct date/time. Try adding a step in Make.com to log or output the bookingUid and seatUid right before the cancellation call, and compare them to the details of the booking you want to cancel. If your mapping is selecting the first result in a list, or not filtering by both date and UID, it could target the wrong booking. Filtering by both date/time and UID in your scenario should help ensure the right booking is cancelled. If you can share a sample of the mapped data or payload, I can help pinpoint where the mapping might be going wrong. For reference, the API logic and validation are described here <https://github.com/calcom/cal.com/blob/e237749abd2c818e507f690787d3842c2f3043ca/apps/api/v2/src/ee/bookings/2024-08-13/services/bookings.service.ts> . *To reply, just mention @dosu <https://go.dosu.dev/dosubot>.* ------------------------------ How did I do? Good <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=great_response> | Irrelevant <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=irrelevant_answer> | Incorrect <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=incorrect_sources> | Verbose <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=too_verbose> | Hallucination <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=hallucination> | Report 🐛 <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=bug_report> | Other <https://app.dosu.dev/response-feedback/edca1103-9bd3-44e2-a247-0b3de9fb521d?feedback_type=other> [image: Chat with Dosu] <https://app.dosu.dev/af5cfe6f-229f-4840-8b4e-da82d0bb1ac6/ask?utm_source=github> [image: Join Discord] <https://go.dosu.dev/discord-bot> [image: Share on X] <https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/calcom/cal.com/discussions/23095> — Reply to this email directly, view it on GitHub <#23095 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVYFZMDJJEEBJPFB6SIJHVL3NS23HAVCNFSM6AAAAACD5E3BSCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJQGY2DENI> . You are receiving this because you were mentioned.Message ID: <calcom/cal. ***@***.***>

[dosubot[bot]]

The most likely reason your Make.com "get bookings" module is returning empty output—even though variables inside show data—is either overly restrictive query parameters or incorrect mapping of the API response. The Cal.com API uses strict AND logic for all filters: if any parameter (like attendeeName, eventTypeId, afterStart, beforeEnd) doesn't match exactly, the result will be an empty array, even if other variables show data inside the module. Date filters must be ISO-8601 strings and all values must be exact matches—no partial or fuzzy matching is performed reference.

To troubleshoot: try relaxing or removing some query parameters (for example, omit attendeeName or date filters) and see if bookings are returned. Also, make sure your mapping in Make.com is set to iterate over the data array in the API response, not just referencing a single path—if you don't iterate, the output will be empty even if the variables show data reference.

If you still get empty output, check the scenario run log for errors or warnings, and share your exact query parameters and a sample of the raw JSON response—this will help pinpoint if it's a filter or mapping issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[salihj09-art]

How do I make sure my mapping in make.com is set to iterate over the data array @dosu

[dosubot[bot]]

To make sure your mapping in Make.com is set to iterate over the data array from the Cal.com API response, add a "Iterator" module right after your HTTP GET module that fetches bookings. In the Iterator's settings, set the source array to the path of the bookings array—usually data (e.g., 52.Data.data if your HTTP module is #52). This will process each booking object one at a time in the scenario.

After the Iterator, you can map fields like uid (bookingUid), attendees[].seatUid, etc., for use in downstream modules (like cancellation or logging). If you skip the Iterator and reference only data[0], Make.com will only process the first booking, which can cause the wrong booking to be affected or empty output—even if variables inside show correct data. Always use the Iterator to ensure each booking in the array is handled individually source.

If your output is still empty, double-check that your query parameters aren't too restrictive and that the array path is correct. You can preview the scenario run to confirm each booking is being iterated and mapped as expected.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[salihj09-art]

@dosu what Is this error

[dosubot[bot]]

The 403 Forbidden InvalidConfigurationError usually means your request was blocked before it reached the Cal.com backend—most likely by infrastructure like AWS CloudFront or an API gateway, not by Cal.com’s application code. This often happens due to issues like an invalid or missing API key, incorrect endpoint URL, missing required headers (like Authorization, Content-Type, or cal-api-version), or IP/rate limiting rules.

Here’s what you should check:

• Make sure your Authorization header contains a valid Bearer API key (not expired, correct prefix, and tied to a user).
• Double-check the endpoint URL—use POST to /v2/bookings/{bookingUid}/cancel for cancellations, not GET.
• Confirm all required headers are present: Content-Type: application/json and cal-api-version: 2024-08-13.
• If you’re behind a proxy or using Make.com, ensure your IP isn’t being blocked or rate-limited by CloudFront or any firewall.
• Try sending the same request with curl or Postman to see if it works outside Make.com. If it does, the issue is with Make.com’s configuration.

If you still get the error, share the full raw request/response (including headers, but redact sensitive info) so we can pinpoint the misconfiguration.

For more on how Cal.com handles authentication and errors, see the backend logic and error handling here:
API Auth Strategy
HTTP Exception Filter

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}