Is your feature request related to a problem?
The current onboarding API does require an explicit Google provider. This could lead to confusion and improper use, especially as we plan to deprecate the vanilla google option.
Describe the solution you'd like
- Create a v2 onboarding API that requires explicit
google_ai_studio or google_gcp.
- Maintain v1 for a transition period, marked for deprecation.
- Implement a scope split: v2 code is added now, but actual credential storage via API is deferred based on usage.
- Retain vanilla
google routing logic for existing rows.
- Update the v2 onboarding table in the design document while keeping the rest unchanged.
- Communicate changes for client configurations clearly to avoid disruption.
Additional Details
Add 32 KB size limit for onboarding payload. Add a constant variable instead of env variable.
Original issue
Context
From the Google provider toggling design 1:1. The onboarding API needs a v2 that requires an explicit Google provider, while v1 stays alive but is marked for deprecation.
Requirements
- v1: accepts only vanilla
google. Kept alive, marked for deprecation.
- v2: requires explicit
google_ai_studio or google_gcp; vanilla google not accepted.
- Scope split: v2 code lands in the current PR, but actual use of the API to write GCP/AI Studio credential rows is deferred — we monitor usage first, then add rows. Mark this clearly in the doc: v2 onboarding API = in current scope; actual credential storage via API = deferred.
- Internally keep the vanilla-
google routing logic regardless, since those rows will exist.
- Expand the v2 onboarding table in the design doc (rest of the doc stays as-is).
Client communication (must not forget)
Once the env var flips to google_gcp in prod:
- All vanilla
google traffic moves to GCP.
google in config becomes opaque — we decide internally what it points to, with no guaranteed notification.- Anyone specifically needing AI Studio must write
google_ai_studio explicitly.
- Share the resolution table with tenants as part of this comms. No existing tenant breaks today.
Additional Details
Add 32 KB size limit for onboarding payload. Add a constant variable instead of env variable.
Is your feature request related to a problem?
The current onboarding API does require an explicit Google provider. This could lead to confusion and improper use, especially as we plan to deprecate the vanilla
googleoption.Describe the solution you'd like
google_ai_studioorgoogle_gcp.googlerouting logic for existing rows.Additional Details
Add 32 KB size limit for onboarding payload. Add a constant variable instead of env variable.
Original issue
Context
From the Google provider toggling design 1:1. The onboarding API needs a v2 that requires an explicit Google provider, while v1 stays alive but is marked for deprecation.
Requirements
google. Kept alive, marked for deprecation.google_ai_studioorgoogle_gcp; vanillagooglenot accepted.googlerouting logic regardless, since those rows will exist.Client communication (must not forget)
Once the env var flips to
google_gcpin prod:googletraffic moves to GCP.googlein config becomes opaque — we decide internally what it points to, with no guaranteed notification.google_ai_studioexplicitly.Additional Details
Add 32 KB size limit for onboarding payload. Add a constant variable instead of env variable.