chore: Update frontend route calls to use new endpoints

[Danelegend]

Description

There are currently some more frontend places that don't make use of the new routes. This updates them to use the new routes

How Has This Been Tested?

...

Additional Options

• [Optional] Please cherry-pick this PR to the latest release version.
• [Optional] Override Linear Check

---

Summary by cubic

Updated frontend LLM routes to use the new admin endpoints and payloads, aligning with backend changes. This also updates response parsing and tests to match the new API shape.

• Refactors
  • Switched default routes to ${LLM_ADMIN_URL}/default and ${LLM_ADMIN_URL}/default-vision with JSON { provider_id, model_name }.
  • Updated fetchVisionProviders to read providers from LLMProviderResponse.
  • Onboarding derives model_name from default_model_name or first model_configurations entry, then sets default via the new route.
  • Adjusted CustomModal test to assert the new endpoint, JSON body, and Content-Type header.

^{Written for commit 19d8ee3. Summary will update on new commits.}

[github-actions]

Preview Deployment

Status	Preview	Commit	Updated
✅	https://onyx-preview-nsufa7rfd-danswer.vercel.app	19d8ee3	2026-02-27 09:02:49 UTC

[greptile-apps]

Greptile Summary

Updated frontend calls to use new unified LLM provider endpoints. The changes migrate from provider-specific parameterized URLs (e.g., /api/admin/llm/provider/{id}/default) to unified endpoints (/api/admin/llm/default, /api/admin/llm/default-vision) that accept request bodies with provider_id and model_name fields.

Key Changes:

• visionLLM.ts: Updated setDefaultVisionProvider to use POST body instead of query parameters, and properly parse LLMProviderResponse wrapper structure
• OnboardingFormWrapper.tsx: Updated default provider endpoint with logic to extract model name from payload
• CustomModal.test.tsx: Updated test assertions to match new endpoint structure

All changes are consistent with the backend API migration and maintain the same functionality while using the new routing structure.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes are straightforward endpoint migrations that align with the backend API structure. The code correctly transforms from parameterized URLs to request bodies, includes appropriate error handling, and maintains existing functionality. Tests have been updated to match the new endpoints.
• No files require special attention

Important Files Changed

Filename	Overview
web/src/lib/llmConfig/visionLLM.ts	Updated to use new /api/admin/llm/default-vision endpoint with request body instead of query parameters, and properly parse LLMProviderResponse structure
web/src/refresh-components/onboarding/forms/OnboardingFormWrapper.tsx	Updated to use new /api/admin/llm/default endpoint with request body containing provider_id and model_name
web/src/sections/modals/llmConfig/CustomModal.test.tsx	Updated test assertions for new endpoint; test could be more thorough by validating model_name field in request body

_{Last reviewed commit: da3f8b2}

[greptile-apps]

_{3 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

also verify model_name field is present in body

Suggested change

	body: expect.stringContaining('"provider_id":5'),
	body: expect.stringContaining('"provider_id":5'),
	body: expect.stringContaining('"model_name"'),

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="web/src/sections/modals/llmConfig/CustomModal.test.tsx">

<violation number="1" location="web/src/sections/modals/llmConfig/CustomModal.test.tsx:442">
P2: Duplicate `body` keys in the matcher cause the `provider_id` assertion to be overwritten, weakening the test and allowing regressions in request payload validation.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: Duplicate body keys in the matcher cause the provider_id assertion to be overwritten, weakening the test and allowing regressions in request payload validation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At web/src/sections/modals/llmConfig/CustomModal.test.tsx, line 442:

<comment>Duplicate `body` keys in the matcher cause the `provider_id` assertion to be overwritten, weakening the test and allowing regressions in request payload validation.</comment>

<file context>
@@ -439,6 +439,7 @@ describe("Custom LLM Provider Configuration Workflow", () => {
           method: "POST",
           headers: { "Content-Type": "application/json" },
           body: expect.stringContaining('"provider_id":5'),
+          body: expect.stringContaining('"model_name"'),
         })
       );
</file context>