calcom/cal.diy · error · BadRequestException

Invalid integration: ${location.integration}

Error message

Invalid integration: ${location.integration}

What it means

Thrown by InputBookingsService.transformLocation when location.type === 'integration' but location.integration is not a key in apiToInternalintegrationsMapping (locations.ts:14). BadRequestException (HTTP 400). The mapping covers the supportedIntegrations list (cal-video, google-meet, zoom, whereby-video, etc.); anything else is rejected.

Source

Thrown at apps/api/v2/src/platform/bookings/2024-08-13/services/input.service.ts:315

      }

      if (isPhoneNumber(location)) {
        return {
          value: "phone",
          optionValue: location,
        };
      }

      return {
        value: "somewhereElse",
        optionValue: location,
      };
    }

    if (location.type === "integration") {
      const integration = apiToInternalintegrationsMapping[location.integration];
      if (!integration) {
        throw new BadRequestException(`Invalid integration: ${location.integration}`);
      }
      return {
        value: integration,
        optionValue: "",
      };
    }

    if (location.type === "address") {
      return {
        value: "inPerson",
        optionValue: "",
      };
    }

    if (location.type === "attendeeAddress") {
      return {
        value: "attendeeInPerson",
        optionValue: location.address,

View on GitHub (pinned to 176037d0af)

Solutions

  1. Use one of the exact supportedIntegrations values from location.input.ts (e.g. 'zoom', 'google-meet', 'cal-video').
  2. Match casing and hyphenation exactly — values are lowercase-kebab.
  3. If the desired integration is missing, request it be added rather than sending a custom slug.
  4. Re-check the supported list after upgrading the platform-types package.

Example fix

// before
location: { type: 'integration', integration: 'Zoom' }

// after
location: { type: 'integration', integration: 'zoom' }
Defensive patterns

Strategy: type-guard

Validate before calling

import { supportedIntegrations } from '@calcom/platform-types/bookings/2024-08-13/inputs/location.input';
if (!supportedIntegrations.includes(body.location.integration)) throw new Error('unsupported integration slug');

Type guard

import { supportedIntegrations } from '@calcom/platform-types/bookings/2024-08-13/inputs/location.input';
const isSupportedIntegration = (s: string): s is typeof supportedIntegrations[number] =>
  (supportedIntegrations as readonly string[]).includes(s);

Try / catch

try { await api.post('/v2/bookings', body); }
catch (e) {
  if (e.response?.status === 400 && /Invalid integration/.test(e.response.data.message)) {
    /* correct the integration slug to a supported value and retry */
  } else throw e;
}

Prevention

When it happens

Trigger: POST /v2/bookings with body.location = { type: 'integration', integration: <unsupported value> }. The class-validator IsIn(supportedIntegrations) on the DTO normally catches this earlier, but transformLocation re-checks defensively and throws if an unknown integration reaches it (e.g. validation bypassed, or a value present in no list).

Common situations: Sending a bare app name like 'zoom' is valid, but 'Zoom', 'zoom_video', 'zoom-video', or 'integrations:zoom' are not; using a slug from a different Cal API version; custom/legacy integration slugs that were renamed; client enum out of sync with supportedIntegrations.

Related errors


AI-assisted analysis of calcom/cal.diy@176037d0af (2026-08-12). Data as JSON: /api/errors/7ca9bf32dd5268a4. Report an issue: GitHub.