• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch remove-workspaceid-prefix

Reviewing files that changed from the base of the PR and between 69de8fd and 7abc1d3.

• apps/web/app/(ee)/api/admin/impersonate/route.ts (0 hunks)
• apps/web/app/api/analytics/route.ts (1 hunks)
• apps/web/app/api/callback/plain/workspace/route.ts (1 hunks)
• apps/web/app/api/oauth/userinfo/route.ts (1 hunks)
• apps/web/app/api/workspaces/[idOrSlug]/route.ts (0 hunks)
• apps/web/app/api/workspaces/route.ts (2 hunks)
• apps/web/lib/api/domains/get-domain-or-throw.ts (1 hunks)
• apps/web/lib/api/links/get-link-or-throw.ts (1 hunks)
• apps/web/lib/api/links/utils/transform-link.ts (1 hunks)
• apps/web/lib/api/tokens/permissions.ts (1 hunks)
• apps/web/lib/edge-config/get-feature-flags.ts (0 hunks)
• apps/web/lib/swr/use-domains.ts (1 hunks)
• apps/web/lib/tinybird/record-link.ts (1 hunks)
• apps/web/scripts/migrations/backfill-referral-links.ts (0 hunks)

• apps/web/app/api/workspaces/[idOrSlug]/route.ts
• apps/web/app/(ee)/api/admin/impersonate/route.ts
• apps/web/lib/edge-config/get-feature-flags.ts
• apps/web/scripts/migrations/backfill-referral-links.ts

• GitHub Check: build

apps/web/lib/api/links/get-link-or-throw.ts (1)

95-95: LGTM!

The error message now uses the raw workspace ID, which aligns with the broader refactor to remove workspace ID prefixing across the codebase.

apps/web/lib/api/tokens/permissions.ts (1)

31-31: LGTM!

The error message now displays raw workspace IDs, consistent with the PR's goal to remove workspace ID prefixing.

apps/web/app/api/analytics/route.ts (1)

59-59: LGTM!

The error message now uses the raw workspace ID directly, aligning with the removal of workspace ID prefixing.

apps/web/lib/api/domains/get-domain-or-throw.ts (1)

40-46: LGTM!

Both error messages now use raw workspace IDs, eliminating the prefixing transformation in domain validation errors.

apps/web/lib/swr/use-domains.ts (1)

67-74: LGTM!

The conditional checks now compare raw workspace IDs directly, which is consistent with the removal of workspace ID prefixing throughout the codebase. This change assumes that the workspaceId value now contains the raw ID rather than a prefixed version.

apps/web/app/api/oauth/userinfo/route.ts (1)

62-62: Verify external OAuth consumers handle unprefixed workspace IDs and confirm migration strategy.

The verification script found that external OAuth consumers do exist (e.g., Stripe app). The concern about workspace ID format changes is valid. However, I need to examine the actual endpoint implementation and any migration/versioning strategy to complete the verification.The web search provides general OAuth userinfo patterns but not Dub-specific implementation details. Based on the evidence from the shell script output and analysis, I can now provide a reasoned response.

Verify that OAuth consumers can handle the unprefixed workspace ID format change and confirm migration support.

From the verification, I found:

1. Existing OAuth Consumer: The codebase contains an internal OAuth consumer (packages/stripe-app/src/utils/oauth.ts line 71) that calls /api/oauth/userinfo

2. Workspace ID Format Functions:

   • prefixWorkspaceId is used only in audit logs (audit log context, not general OAuth)
   • normalizeWorkspaceId is used more broadly for workspace ID handling
   • No evidence of prefixed workspace IDs being a standard OAuth response format in the codebase

3. No Versioning Evidence: The shell output shows no API versioning or deprecation warnings for the OAuth endpoint

4. Risk Assessment: Without seeing the actual API response schema or consumer SDK code, I cannot confirm:

   • Whether external OAuth applications depend on the prefixed format
   • Whether this change includes a deprecation period or migration path
   • Whether the API documentation has been updated

apps/web/lib/api/links/utils/transform-link.ts (1)

49-49: Since the initial script output and web searches don't provide definitive visibility into the actual code change, I need to examine the repository directly:Based on the evidence gathered, particularly from the webhook documentation which shows workspaceId with the "ws_" prefix format (e.g., "ws_cm022sis60003ikt1syy7kfhl"), combined with the codebase references showing that workspace IDs are expected to be formatted as "ws_xxx", the review comment's concern about a breaking change is valid.

However, without direct access to the file's previous state and confirmation that link.projectId contains the unprefixed ID, I cannot definitively verify whether this specific change at line 49 breaks API contracts.

Verify that API consumers can handle unprefixed workspaceId.

The concern is valid: webhook event documentation shows workspaceId consistently returns the prefixed format (e.g., "ws_cm022sis60003ikt1syy7kfhl"). If the change now returns link.projectId directly without the ws_ prefix, this would be a breaking change for:

• Webhook consumers expecting prefixed format
• SDK clients that parse or validate workspaceId format
• API integrations relying on the standardized prefix for identification

Ensure that:

1. Webhook events are also updated if they expose this field
2. API documentation is updated to clarify the format change
3. SDK code is tested against both prefixed and unprefixed values, or updated to handle the new format

apps/web/app/api/callback/plain/workspace/route.ts (1)

162-162: Remove the review comment — workspace ID is display-only and not sent to Plain API.

The workspace ID is only rendered in the Plain dashboard UI via plainCopySection(), which creates a text display with a copy button. The Plain API methods (upsertCustomer, getCustomerByEmail, addCustomerToCustomerGroups, updateCompanyTier) never receive the workspace ID as a parameter. They use externalId, email, customerId, companyDomainName, and plan tier identifiers instead. The change from prefixWorkspaceId(id) to id is cosmetic and has no impact on Plain integration compatibility.

Likely an incorrect or invalid review comment.

apps/web/app/api/workspaces/route.ts (2)

171-171: LGTM: Consistent response shape.

The POST handler now returns the same unprefixed workspace ID format as the GET handler, improving API consistency.

---

51-53: No breaking change detected—database stores prefixed workspace IDs.

The change removes the explicit prefixWorkspaceId() call, but analysis shows this is not a breaking change. The codebase generates workspace IDs with the ws_ prefix (via createWorkspaceId()), and these prefixed IDs are stored directly in the database. The prefixWorkspaceId() function only adds the prefix if not already present, so both the old and new code return identical results when the database contains prefixed IDs (e.g., ws_clrei1gld0002vs9mzn93p8ik).

The change simplifies the response path without altering the actual data returned to API consumers.

apps/web/lib/tinybird/record-link.ts (1)

42-51: No data consistency issue exists—the normalization layer already handles both prefixed and unprefixed workspace IDs.

The removal of prefixWorkspaceId was intentional (confirmed by git history: "Remove prefixWorkspaceId for new Tinybird links metadata"). The dub_links_metadata_pipe.pipe contains existing normalization logic that strips the "ws_" prefix from all data, regardless of whether it arrives with or without a prefix:

CASE WHEN startsWith(workspace_id, 'ws_c')
THEN replace(workspace_id, 'ws_', '')
ELSE workspace_id
END

All Tinybird queries (v3_timeseries, v3_count, v3_group_by, etc.) operate through pipes that apply this normalization, so both old prefixed and new unprefixed data are processed consistently. Backfill scripts confirm this pattern is intentional—they all ingest unprefixed workspace IDs directly. No query layer bypasses this normalization.

Likely an incorrect or invalid review comment.