feat: multiple credentials options

[zhubzy]

No description provided.

[zhubzy]

Suggested PR title from Pearl

Title: feat(credentials, fub): Implement alternative authentication methods (credential groups)

Body:
This PR introduces a robust system for managing alternative authentication methods for services, allowing users to choose one from a group of supported credential types instead of requiring all of them individually. This significantly improves the user experience for services like Follow Up Boss, which support both OAuth and API Key authentication.

Key Changes:

• Credential Groups (New Feature):
  • Introduced CREDENTIAL_GROUPS in @bubblelab/shared-schemas to define sets of CredentialTypes that represent alternative authentication methods for a single service (e.g., Follow Up Boss OAuth vs. API Key).
  • Added helper functions (getAlternativeCredentialsGroup, getCredentialTypeLabel, etc.) to facilitate working with these groups.
• Centralized Credential Validation:
  • Implemented validateCredentialSelection in @bubblelab/shared-schemas. This new function provides a single source of truth for checking if required credentials are met, intelligently handling both individual and grouped (alternative) credential types.
  • Replaced existing, manual credential validation logic in BubbleNode.tsx and useRunExecution.ts with calls to validateCredentialSelection, ensuring consistent and correct validation across the application.
• Enhanced UI for Credential Selection:
  • BubbleNode (BubbleNode.tsx): The credential selection dropdown now intelligently detects if required credential types belong to a group. If so, it renders a single dropdown with <optgroup> elements, allowing users to select one credential from the available alternatives (e.g., "OAuth" or "API Key").
  • Credentials Page (CredentialsPage.tsx): Credentials belonging to a defined group are now visually grouped under a single service card, providing a cleaner and more intuitive overview of a service's authentication options.
  • Create Credential Modal: Updated the modal to better support grouped credentials, allowing the user to select the specific type within a group when adding a new credential.
• Follow Up Boss Integration:
  • Added CredentialType.FUB_API_KEY_CRED to support API Key authentication for Follow Up Boss.
  • The Follow Up Boss bubble (followupboss.ts) now prioritizes OAuth credentials but falls back to API Key authentication (using Basic Auth) if OAuth is not provided.
  • Expanded the Follow Up Boss bubble with new operations: list_events and get_event, along with their respective schemas.
• Documentation:
  • Updated CREATE_BUBBLE_README.md with a new section "Alternative Auth Methods (Credential Groups)" to guide developers on configuring services with multiple authentication options.
• Environment Variables:
  • Updated .env.example with new FUB-related environment variables (FUB_OAUTH_CLIENT_ID, FUB_OAUTH_CLIENT_SECRET, FUB_SYSTEM_NAME, FUB_SYSTEM_KEY).

This feature significantly improves the flexibility and usability of credential management, especially for services that offer multiple ways to authenticate.

---

🚀 "Build in Public" Social Media Content

Google Doc Created: View Document

Suggested X Post:
Shipping a game-changer for #BubbleLab! 🚀 Tired of services demanding ALL auth types when you only use one? We've rolled out 'Credential Groups' – choose OAuth or API Key. Huge win for UX & dev flexibility! Learned a ton abstracting auth. What's your biggest auth challenge? #BuildInPublic #DevCommunity #APIs

Suggested LinkedIn Post:
Ever tackled the complexities of managing diverse authentication methods for third-party services? 🔐 We certainly have, and it led us to a significant architectural enhancement at BubbleLab!

I'm excited to share a recent PR that introduces Credential Groups – a robust system designed to empower users with choice and simplify our integration ecosystem.

What's the challenge? Traditionally, services might demand specific, individual credentials. But what about services like Follow Up Boss that support both OAuth and API Keys? Forcing users to provide all options creates unnecessary friction.

Our Solution: Credential Groups!

💡 Technical Highlights & Achievements:

1. Schema-Driven Flexibility: We introduced CREDENTIAL_GROUPS in @bubblelab/shared-schemas. This allows us to define sets of alternative CredentialTypes, providing a blueprint for flexible authentication options.
2. Centralized Validation: A new validateCredentialSelection function now acts as a single source of truth. This intelligent validator ensures consistent and correct credential checks across the application, replacing scattered manual logic and significantly boosting reliability.
3. Enhanced User Experience: The UI now intelligently renders credential selection. If a service has grouped credentials, users see a single dropdown with <optgroup> elements, allowing them to effortlessly pick their preferred authentication method (e.g., OAuth vs. API Key).
4. Real-World Impact (Follow Up Boss): We've integrated FUB_API_KEY_CRED, allowing Follow Up Boss to prioritize OAuth but gracefully fall back to API Key authentication. This is a game-changer for user flexibility.

This wasn't just about adding a feature; it was about rethinking our core credential management architecture to be more flexible, scalable, and user-centric. It's a testament to building systems that adapt to real-world complexities while maintaining a clean developer experience.

What we learned: Designing for flexibility from the schema level up can drastically simplify future integrations and improve overall system resilience. Centralizing validation logic is key to consistency and maintainability in complex applications.

How do you approach managing diverse authentication methods in your projects? Share your insights below!

#SoftwareDevelopment #FrontendDevelopment #BackendDevelopment #Architecture #SystemDesign #APIs #Authentication #DevOps #ProductDevelopment #BubbleLab #OpenSource #DeveloperExperience

[Copilot]

Pull request overview

This PR implements support for multiple authentication methods for services, specifically adding API Key authentication as an alternative to OAuth for Follow Up Boss. The implementation introduces a credential grouping system that allows users to choose between alternative authentication methods rather than requiring all of them.

Key Changes:

• Added FUB_API_KEY_CRED credential type with support for Basic authentication
• Implemented credential groups configuration to mark alternative auth methods
• Enhanced UI to display grouped credentials with a unified selector and validation logic

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
packages/bubble-shared-schemas/src/types.ts	Added new FUB_API_KEY_CRED credential type enum
packages/bubble-shared-schemas/src/credential-schema.ts	Introduced CredentialGroupConfig interface, CREDENTIAL_GROUPS configuration, and validation functions for handling alternative credentials
packages/bubble-shared-schemas/src/bubble-definition-schema.ts	Registered FUB_API_KEY_CRED in credential configuration map
packages/bubble-core/src/bubbles/service-bubble/followupboss.ts	Implemented getAuthHeader() method to support both OAuth (Bearer) and API Key (Basic) authentication; added list_events and get_event operations
packages/bubble-core/src/bubbles/service-bubble/followupboss.test.ts	Added debug console.log statements (should be removed)
packages/bubble-core/src/bubbles/service-bubble/gemini-2.5-flash-reliability.integration.test.ts	Contains unrelated test changes that should be separated or reverted
packages/bubble-core/CREATE_BUBBLE_README.md	Added comprehensive documentation for configuring alternative auth methods with credential groups
apps/bubblelab-api/.env.example	Added environment variables for FUB OAuth and system configuration
apps/bubble-studio/src/pages/CredentialsPage.tsx	Implemented grouped credential display in the credentials page with separate cards showing credentials by type label; added allowedCredentialTypes filter for the create modal
apps/bubble-studio/src/hooks/useRunExecution.ts	Updated credential validation to use centralized validateCredentialSelection() function
apps/bubble-studio/src/components/BubbleNode.tsx	Enhanced credential selector to display grouped credentials with optgroup labels and handle selection/deselection of alternative credentials

[Copilot]

The OPENAI_CRED credential is added but never used in the test. The test uses google/gemini-2.5-flash model which only requires GOOGLE_GEMINI_CRED. This unused credential should be removed to avoid confusion.

Suggested change

[CredentialType.OPENAI_CRED]: process.env.OPENAI_API_KEY!,

[Copilot]

[nitpick] The getAlternativeCredentialsGroup function returns null when types.length < 2, but this might not be the desired behavior for a single credential type that belongs to a group. If a bubble requires only one type (e.g., only FUB_API_KEY_CRED), this function will return null even though it's part of a group.

This could cause UI inconsistencies where a single credential from a group is not treated as part of that group. Consider whether the function should return the group config for single credential types that belong to a group, or document why this behavior is intentional.

Suggested change

	if (types.length < 2) return null;
	if (types.length === 0) return null;
	if (types.length === 1) {
	const groupName = getCredentialGroupName(types[0]);
	return groupName ? CREDENTIAL_GROUPS[groupName] : null;
	}

[Copilot]

The chooseCredential method prioritizes FUB_API_KEY_CRED over FUB_CRED, but getAuthHeader (which actually uses the credentials) prioritizes FUB_CRED (OAuth) over FUB_API_KEY_CRED. This inconsistency could lead to confusion about which credential type takes precedence.

Recommendation: Make the priority consistent. Since OAuth is generally more secure and the comment in getAuthHeader indicates "OAuth takes priority", update chooseCredential to match this priority order (check FUB_CRED first, then FUB_API_KEY_CRED).

Suggested change

	if (credentials[CredentialType.FUB_API_KEY_CRED]) {
	return credentials[CredentialType.FUB_API_KEY_CRED];
	}
	if (credentials[CredentialType.FUB_CRED]) {
	return credentials[CredentialType.FUB_CRED];
	}
	if (credentials[CredentialType.FUB_CRED]) {
	return credentials[CredentialType.FUB_CRED];
	}
	if (credentials[CredentialType.FUB_API_KEY_CRED]) {
	return credentials[CredentialType.FUB_API_KEY_CRED];
	}

[Copilot]

The removal of as const from the model string removes type safety. Without as const, the type is widened from a specific string literal to a general string, which could allow invalid model names. Consider keeping as const for better type safety.

Suggested change

	model: 'google/gemini-2.5-flash',
	model: 'google/gemini-2.5-flash' as const,

[Copilot]

[nitpick] Changing temperature from 0.3 to 1 significantly increases randomness in AI responses. For a reliability test, higher temperature (1) introduces more variability, which may make the test less stable and harder to diagnose failures. If this change is intentional for testing different temperature settings, it should be documented. Otherwise, consider reverting to 0.3 for consistency with the test's purpose.

Suggested change

	temperature: 1,
	temperature: 0.3,

[Copilot]

[nitpick] The value parsing logic using split(':') is fragile. If a credential type name contains a colon (though unlikely), this would break. Consider using a more robust delimiter or a different encoding method (e.g., split(':', 2) to limit splits, or using JSON encoding).

Suggested change

	const [credType, credIdStr] = val.split(':');
	const [credType, credIdStr] = val.split(':', 2);

[Copilot]

The changes to gemini-2.5-flash-reliability.integration.test.ts appear to be unrelated to the "multiple credentials options" feature. These include:

• Updated test message content (calendar events)
• Removed as const from model declaration
• Temperature change from 0.3 to 1
• Added unused OPENAI_CRED credential
• Formatting changes to the test message
• Missing iteration count in console output
• Removed duplicate test case

If these changes are intentional, they should be in a separate PR. If they're accidental, they should be reverted to keep this PR focused on the credential feature.

[Copilot]

Debug console.log statement should be removed before merging to production. This appears to be leftover debugging code.

[Copilot]

The console output message is missing the number of iterations. It should read "All 20 parallel requests completed" or use the numIterations variable: All ${numIterations} parallel requests completed.

Suggested change

	`\n⏱️ All parallel requests completed in ${overallExecutionTime}ms\n`
	`\n⏱️ All ${numIterations} parallel requests completed in ${overallExecutionTime}ms\n`