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
- Use one of the exact supportedIntegrations values from location.input.ts (e.g. 'zoom', 'google-meet', 'cal-video').
- Match casing and hyphenation exactly — values are lowercase-kebab.
- If the desired integration is missing, request it be added rather than sending a custom slug.
- 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
- Use exact supportedIntegrations slugs (lowercase-kebab).
- Share the supportedIntegrations enum between client and server builds.
- Re-check the list after upgrading platform-types.
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
- Booking location with integration ${inputBookingLocation.int
- Booking location with type ${(location as BookingInputLocati
- Booking location with type ${inputBookingLocation.type} not
- Unsupported integration: ${integrationSlug}
- Attempting to book a meeting in the past.
AI-assisted analysis of calcom/cal.diy@176037d0af (2026-08-12).
Data as JSON: /api/errors/7ca9bf32dd5268a4.
Report an issue: GitHub.