What does this PR do?

Fixes two issues with the Intercom app integration:

1. Expands allowed URL patterns: Removes overly restrictive validation that only allowed URLs with /team/ or /org/ prefixes
2. Prevents double-prefixing: Fixes bug where absolute URLs like https://grow-therapy.cal.com/provider-billing-support/grow-therapy-callback were being incorrectly prefixed with app.cal.com, resulting in malformed URLs like https://app.cal.com/https://grow-therapy.cal.com/...

Changes Made

1. URL Validation (packages/app-store/intercom/lib/isValidCalURL.ts)

• Removed restrictive (team/)?(org/)? pattern from regex
• Now allows any path after the domain: https://[subdomain.]cal.com/...

2. URL Parsing (packages/app-store/intercom/api/get.ts)

• Added logic to detect absolute vs relative URLs
• For absolute URLs: Extracts origin and pathname separately to prevent double-prefixing
• For relative URLs: Maintains existing behavior
• Validates that absolute URLs are for cal.com or *.cal.com domains only

3. URL Encoding (packages/app-store/intercom/api/initialize.ts)

• Added encodeURIComponent when passing URLs as query parameters

Supported URL Patterns

The integration now supports:

• https://app.cal.com/username/event-type
• https://cal.com/username/event-type
• https://subdomain.cal.com/username/event-type (any subdomain)
• https://cal.com/team/teamname/event-type
• Relative paths like /username/event-type

Link to Devin run: https://app.devin.ai/sessions/4d063aa5a62b40839c9f15f129ff6976
Requested by: @PeerRich ([email protected])
Slack thread: https://calendso.slack.com/archives/C08LT9BLEET/p1763194297107149

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

Prerequisites:

• Set up the Intercom app integration in Cal.com
• Have access to an organization with a custom subdomain (e.g., grow-therapy.cal.com)

Test Cases:

1. Test absolute URL with subdomain:

   • Configure Intercom integration with URL: https://grow-therapy.cal.com/provider-billing-support/grow-therapy-callback
   • Expected: URL should work without being double-prefixed with app.cal.com
   • Verify the embed loads correctly with the correct origin

2. Test various URL patterns:

   • https://app.cal.com/username/30min
   • https://cal.com/username/meeting
   • https://subdomain.cal.com/team/teamname/event-type
   • All should be accepted by validation and work correctly

3. Test relative paths (backward compatibility):

   • Configure with relative path like /username/event-type
   • Expected: Should work as before with app.cal.com as origin

4. Test invalid URLs (security):

   • Try https://malicious.com/fake-path
   • Expected: Should be rejected with error message

Human Review Checklist

⚠️ Critical areas to review:

1. URL parsing logic in get.ts (lines 19-38)

   • Does the regex /^https?:\/\//i correctly identify absolute URLs?
   • Are there edge cases not handled (URLs with fragments, special characters, etc.)?
   • Is the hostname validation secure? Could hostname.endsWith(".cal.com") match unintended domains?

2. Cal embed API usage (lines 83-91)

   • Are we using the correct parameters for Cal("init") and Cal("inline")?
   • Does the embed API actually support dynamic origin parameter?
   • Should we be including parsedUrl.search in calLink?

3. Regex change in isValidCalURL.ts

   • Is the new regex too permissive? Could it allow unintended URLs?
   • Should we validate the path structure more strictly?

4. Testing gaps

   • ⚠️ No automated tests were added
   • ⚠️ Changes were not tested with actual Intercom integration
   • ⚠️ The specific failing URL from the user was not manually verified

5. Potential breaking changes

   • Could existing integrations that relied on the /team/ or /org/ restriction break?
   • Are there any other places in the codebase that depend on the old URL format?

Checklist

• I have read the contributing guide
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas (N/A - logic is straightforward)
• I have checked if my changes generate no new warnings