Lovable and Bolt Apps Break on Third-Party APIs: Wrong Endpoints, Missing Secrets, Deprecated Calls

Apps built with Lovable and Bolt break on third-party APIs when the builder fills in details it was never given: the endpoint, the fields, the auth header, and where the key lives. The common results are 404s from wrong paths, 401s from missing or misnamed secrets, CORS errors from calling a provider directly from the browser, keys exposed in the client bundle, and code written against an SDK version the provider has replaced. The fix is to give the builder the real API details up front, keep authenticated calls in a server-side function, and check each request against the provider's schema before trusting it.

This article is for founders and builders shipping apps with Lovable or Bolt. It covers the four ways third-party integrations break, how to diagnose each from the error you see, what to put in the prompt, and where an execution layer helps. Checked against Lovable and Bolt documentation and public troubleshooting guides in October 2026.

Four ways third-party APIs break

Wrong endpoints and fields

Lovable's guide to integrating any API lists what to give it: endpoint URLs and HTTP methods, the authentication method, required headers, request and response examples, and an OpenAPI spec or documentation link. Each item you leave out is one the builder has to infer. Inference works for well-known APIs and fails often on smaller providers, newer API versions, and internal services.

A 404 usually means the path is wrong. A 400 or 422 usually means a field is wrong or missing. Open the browser's network tab or the function's logs, copy the exact request and response, and paste both into the chat. That gives the builder evidence to work from, where a vague "it doesn't work" leaves it guessing again.

Missing and misnamed secrets

In Lovable, authenticated APIs go through the built-in backend. Keys are stored under Cloud, then Secrets, and an Edge Function reads them server-side with Deno.env.get. Secret names are case-sensitive, so STRIPE_SECRET_KEY in Secrets and Stripe_Secret_Key in code are two different things. Lovable's Edge Function view shows invocations and logs for each function, which is where a missing secret shows up.

Bolt projects typically use Vite, which bakes environment variables into the build. A variable added to the host after deployment stays undefined until the app is rebuilt, which is why an integration can work in preview and fail after publishing.

Keys exposed in the browser

Vite exposes any variable prefixed with VITE_ to client-side code. Lovable rejects VITE_-prefixed names in its Secrets manager for this reason, and documents those values as public build-time settings. Troubleshooting guides for Bolt describe generated names such as VITE_STRIPE_SECRET_KEY, which put a secret key in public JavaScript. Calling a provider straight from the browser also runs into CORS, since many APIs block browser requests.

The fix is the same on both platforms. The browser calls your own server function, and that function reads the secret and calls the provider. Ask for this pattern by name.

Deprecated calls

Builders write code from patterns in training data, and older SDK versions often have more examples than current ones. Google's move from @google/generative-ai to @google/genai is a well-documented case where AI tools kept writing the deprecated package. Name the SDK and version you want in the prompt, and check the provider's changelog when a call fails with a removed method or parameter.

What to put in the prompt

Integrate <provider> to <job>.

- Endpoint: <METHOD> <full URL>
- Auth: <header name and format>, stored as the secret <EXACT_NAME>
- Required fields: <field: type, ...>
- Example request and response: <paste>
- SDK: <package>@<version>, or plain fetch
- Call the API only from a server function. The browser calls that function.
- Never use VITE_ or NEXT_PUBLIC_ for any secret.

If you lack these details, collect them before prompting. That is the step most failed integrations skip.

Where Swytchcode fits

Swytchcode is an execution layer between agents and the APIs they call. For the APIs in its catalog, and for internal APIs added from an OpenAPI spec, it holds the real operation schemas. Two parts of it help with a Lovable or Bolt integration:

• swy info <canonical_id> prints the operation's resolved input and output schema: the fields, their types, and which are required. Paste it into the prompt in place of a guessed body.
• Dry runs validate inputs and show the request a call would send, without sending it. Missing or invented fields fail with exit code 1, and an unknown operation fails with exit code 2.

If you sync the project to GitHub and keep working on it with a local coding agent such as Cursor, Claude Code, or Codex, connect that agent to the Swytchcode MCP server. The agent then discovers operations, reads schemas, and runs calls through validation, so it stops writing requests from memory.

# On your machine, in the synced repository
npm install -g swytchcode
swy init --editor=cursor --mode=sandbox
swy doctor

# Find the operation and read the real schema
swy discover "send a transactional email" --json
swy get <project>
swy add <canonical_id>
swy info <canonical_id>

Lovable and Bolt both accept custom MCP servers as connectors, but they connect to remote URLs, and the Swytchcode MCP server runs locally. Use the CLI output as context for the builder instead.

Where this does not help

Swytchcode does not run inside Lovable Edge Functions, Bolt's browser preview, or the published app's frontend. The runtime SDKs expect the CLI and an initialized project on the same machine, so they apply only where you run your own Node.js or Python server. Swytchcode also does not move secrets out of VITE_ variables or fix CORS in your code. Those fixes belong in the generated app, following the patterns above.

Frequently asked questions

Why does my Lovable app get a 401 from an API?
The key is missing, misnamed, or sent in the wrong header. Check that the secret exists under Cloud, then Secrets, that its name matches the Deno.env.get call exactly, and that the Edge Function was redeployed after the change.

Why does my Bolt app work in preview but fail after deploying?
Vite bakes environment variables into the build. If a variable was added to the host after the build, or lacks the prefix the code expects, it stays undefined until you rebuild and redeploy.

Is it safe to put API keys in VITE_ variables?
Only for values meant to be public, such as a Supabase publishable key protected by row-level security. Any VITE_ variable is compiled into JavaScript that visitors can read.

How do I stop Lovable or Bolt from guessing API endpoints?
Give it the endpoint, method, auth header, required fields, and an example request and response, or the provider's OpenAPI spec. Lovable's own documentation asks for exactly these details.

Can Lovable or Bolt use MCP servers?
Yes. Both support MCP connectors, including custom remote servers. In Lovable, chat connectors give the builder context while you work and are never part of the published app.

Swytchcode resources

• Why AI agents call the wrong API: https://www.swytchcode.com/content/why-your-ai-agent-calls-the-wrong-api-and-how-to-fix-it
• Why Replit Agent struggles with Stripe: https://www.swytchcode.com/content/replit-agent-stripe-integration-problems
• Gemini CLI invents API parameters: https://www.swytchcode.com/content/gemini-cli-hallucinated-api-parameters
• Swytchcode MCP server docs: https://docs.swytchcode.com/cli/mcp/
• CLI command reference: https://docs.swytchcode.com/reference/commands/
• Supported APIs: https://www.swytchcode.com/apis