calcom/cal.diy · error · ForbiddenException

BookingPbacGuard - user with id=${user.id} does not have acc

Error message

BookingPbacGuard - user with id=${user.id} does not have access to booking with uid=${bookingUid}

What it means

A 403 ForbiddenException thrown by BookingPbacGuard when the authenticated user passes to the guard (request.user is set) and bookingUid is present, but bookingAccessService.doesUserIdHaveAccessToBooking returns false. This means the user is logged in but has no relationship to this specific booking (not the organizer, not an attendee host, not a team admin with access).

Source

Thrown at apps/api/v2/src/platform/bookings/2024-08-13/guards/booking-pbac.guard.ts:51

    if (!user) {
      throw new UnauthorizedException();
    }

    if (!bookingUid) {
      throw new BadRequestException(
        "BookingPbacGuard - bookingUid is required"
      );
    }

    const hasAccess =
      await this.bookingAccessService.doesUserIdHaveAccessToBooking({
        userId: user.id,
        bookingUid,
      });

    if (!hasAccess) {
      throw new ForbiddenException(
        `BookingPbacGuard - user with id=${user.id} does not have access to booking with uid=${bookingUid}`
      );
    }

    request.pbacAuthorizedRequest = true;
    return true;
  }
}

View on GitHub (pinned to 176037d0af)

Solutions

  1. Verify the bookingUid belongs to the authenticated user or a team they manage — call GET /v2/bookings/:bookingUid with the same token to confirm access.
  2. If the user should have access, check their team membership and role in the Cal.com dashboard — they may need to be added as a team admin.
  3. Ensure you're using the correct API key or OAuth token for the user who owns the booking.
  4. If the booking was moved to a different team, update the user's team membership accordingly.

Example fix

// before — using wrong user's token to access someone else's booking
PATCH /v2/bookings/abc-123
Authorization: Bearer <user-A-token>
// booking abc-123 belongs to user-B -> 403

// after — use the booking owner's token or a team admin's token
PATCH /v2/bookings/abc-123
Authorization: Bearer <user-B-token>  // or a team admin token
// -> 200
Defensive patterns

Strategy: validation

Validate before calling

// Verify the user has access to the booking before modifying it
async function verifyBookingAccess(token, bookingUid) {
  const res = await fetch(`/v2/bookings/${bookingUid}`, {
    headers: { Authorization: `Bearer ${token}` }
  });
  return res.ok;
}

if (!(await verifyBookingAccess(token, bookingUid))) {
  throw new Error('User does not have access to this booking');
}

Try / catch

try {
  await api.updateBooking(bookingUid, updates);
} catch (err) {
  if (err.statusCode === 403 && err.message.includes('does not have access')) {
    // Use a different token (e.g., the booking owner or team admin)
    throw new Error('Access denied — use the booking owner or team admin credentials');
  }
  throw err;
}

Prevention

When it happens

Trigger: Any PBAC-protected route (e.g., PATCH /v2/bookings/:bookingUid for location updates, attendee management) where the authenticated user tries to access a booking that belongs to a different user or team they're not part of. The bookingAccessService checks ownership, team membership, and organizer relationships.

Common situations: A user tries to modify another user's booking. A team member without admin role tries to access a booking from a private team event type. The booking was transferred to a different organizer. A former team member whose access was revoked still holds a valid API key. Cross-tenant access attempts in multi-tenant org setups.

Related errors


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