How to Vibecode API Integrations

how-to-vibecode-api-integrationsEvery week, another developer posts a build thread: a full-stack app shipped in an afternoon using Cursor, Claude Code, Codex, Lovable, or Bolt.new. Deployed, working, sometimes with paying users. The obvious next question for B2B SaaS teams is whether that same speed applies to integrations. Can you prompt an AI to connect your product to QuickBooks? Get a working Xero sync before the end of the day?

You can. And plenty of teams are doing it. What follows is a practical guide to building API integrations with the most popular vibe coding platforms, starting from scratch. After the how-to, we'll cover where this approach fits into a real product roadmap, where the costs shift, and what to consider if you're building integrations your customers will depend on.

Before you start: what every platform needs

Regardless of which vibe coding tool you pick, connecting to a third-party API like QuickBooks Online requires the same prerequisites. Getting these set up before you open your AI tool of choice will save you from the most common dead ends.

You need a developer account with the API provider. For QuickBooks, that means registering at developer.intuit.com, creating an app, and selecting the Accounting scope. The portal gives you a Client ID and Client Secret for the sandbox environment, plus a sandbox company pre-loaded with test data. This setup takes about 15 minutes.

You also need to configure a Redirect URI in the QuickBooks developer portal. This is the URL where Intuit sends the user after they grant your app access. For local development, this is typically something like http://localhost:3000/callback. For Lovable and Bolt.new, you'll use the deployed URL they generate for your project.

QuickBooks (like most accounting and CRM platforms) uses OAuth 2.0 Authorization Code flow exclusively. There are no API keys or basic auth options. The flow works in four steps: your app redirects the user to Intuit's authorization page, the user grants permission, Intuit redirects back to your app with an authorization code, and your app exchanges that code for an access token and a refresh token. Access tokens expire after one hour. Refresh tokens last 100 days but rotate on each use.

Building a QuickBooks invoice integration in Cursor

Cursor is an AI-powered IDE built on VS Code that reads your entire codebase for context. Its suggestions account for your existing backend structure, database schema, and error handling patterns, and you review every change through visual diffs before it's applied. For this walkthrough, we'll build a Node.js module that authenticates with QuickBooks and fetches invoices. (If you want the full native integration guide without vibe coding, Apideck has a complete walkthrough of integrating with QuickBooks Online that covers the same territory in more depth.)

Step 1: Scaffold the project. Open a terminal and set up a new Node project, or open your existing codebase in Cursor. If starting fresh:

mkdir qb-integration && cd qb-integration
npm init -y
npm install intuit-oauth node-quickbooks express dotenv

Create a .env file with your QuickBooks credentials:

QB_CLIENT_ID=your_client_id_here
QB_CLIENT_SECRET=your_client_secret_here
QB_REDIRECT_URI=http://localhost:3000/callback
QB_ENVIRONMENT=sandbox

Step 2: Generate the OAuth handler. In Cursor, open a new file called auth.js and prompt:

Build an Express route handler for QuickBooks OAuth 2.0. It should:
1. Have a /connect route that redirects to Intuit's authorization URL
   with the accounting scope
2. Have a /callback route that receives the auth code, exchanges it
   for access and refresh tokens, and stores them in memory
3. Have a /refresh route that uses the refresh token to get a new
   access token
Use the intuit-oauth package. Read credentials from environment
variables.

Cursor generates something like this:

require('dotenv').config();
const express = require('express');
const OAuthClient = require('intuit-oauth');

const app = express();

const oauthClient = new OAuthClient({
  clientId: process.env.QB_CLIENT_ID,
  clientSecret: process.env.QB_CLIENT_SECRET,
  environment: process.env.QB_ENVIRONMENT,
  redirectUri: process.env.QB_REDIRECT_URI,
});

// Store tokens in memory (replace with database in production)
let tokenStore = {};

app.get('/connect', (req, res) => {
  const authUri = oauthClient.authorizeUri({
    scope: [OAuthClient.scopes.Accounting],
    state: 'random-state-value',
  });
  res.redirect(authUri);
});

app.get('/callback', async (req, res) => {
  try {
    const authResponse = await oauthClient.createToken(req.url);
    tokenStore = {
      accessToken: authResponse.getJson().access_token,
      refreshToken: authResponse.getJson().refresh_token,
      realmId: req.query.realmId,
      expiresAt: Date.now() + 3600000, // 1 hour
    };
    res.send('Connected to QuickBooks successfully');
  } catch (err) {
    res.status(500).send('Authentication failed: ' + err.message);
  }
});

app.get('/refresh', async (req, res) => {
  try {
    const authResponse = await oauthClient.refreshUsingToken(
      tokenStore.refreshToken
    );
    tokenStore.accessToken = authResponse.getJson().access_token;
    tokenStore.refreshToken = authResponse.getJson().refresh_token;
    tokenStore.expiresAt = Date.now() + 3600000;
    res.send('Token refreshed');
  } catch (err) {
    res.status(500).send('Refresh failed: ' + err.message);
  }
});

app.listen(3000, () => console.log('Server running on port 3000'));
module.exports = { app, getTokens: () => tokenStore };

Step 3: Add the invoice-fetching logic. Open a new file, invoices.js, and prompt:

Using the node-quickbooks package and the tokens from auth.js,
build a function that fetches all invoices from a QuickBooks
company. Handle pagination (QuickBooks returns max 1000 per query),
check token expiration before each call, and return a clean array
of objects with: invoiceNumber, customerName, totalAmount, dueDate,
status, and balance.

Cursor produces the data-fetching module and the field mapping. The important thing to notice: you now have two separate files with distinct responsibilities. You can review each one, test them independently, and hand them to another developer who can read the code and understand what it does.

Step 4: Test against sandbox. Run node auth.js, open http://localhost:3000/connect in a browser, and walk through the QuickBooks OAuth flow. The sandbox company has pre-populated invoices, so your /invoices endpoint should return data immediately.

The entire process from empty directory to working invoice sync takes about 45 minutes in Cursor, including the time spent reading QuickBooks error messages and re-prompting when the AI gets a parameter wrong (it sometimes confuses the intuit-oauth and node-quickbooks package APIs).

The same integration with Claude Code

Claude Code is Anthropic's terminal-first coding agent. Like Cursor, it reads your full codebase for context. The difference is in how it works: rather than suggesting inline edits you approve one by one, Claude Code plans an approach across multiple files and executes it autonomously. For integration work that touches an auth module, a token storage layer, API routes, and error handling simultaneously, that autonomy saves a lot of back-and-forth.

Start with the same project setup as the Cursor walkthrough (same npm packages, same .env file). Then, from your project directory:

claude

Once inside the Claude Code session, you describe the full integration:

Build a QuickBooks Online integration in this project. I need:
1. An Express OAuth handler with /connect, /callback, and /refresh
   routes using the intuit-oauth package
2. An invoices module that fetches all invoices using node-quickbooks,
   handles pagination, and checks token expiration before each call
3. A /invoices route that returns a clean JSON array with
   invoiceNumber, customerName, totalAmount, dueDate, and status
Read credentials from the .env file. Store tokens in memory for now.

Claude Code creates both files, wires the routes together in a single server.js entry point, and runs the app to verify it starts without errors.

The practical difference from Cursor: you describe the full scope once, and Claude Code creates the file structure and writes across all of them in a single pass. In Cursor, you'd prompt file by file, checking each diff. Both get you to the same output. Claude Code is faster for the initial scaffold; Cursor gives you tighter control over each individual change.

Claude Code also runs in VS Code (as an extension), in JetBrains IDEs, and in the browser at claude.ai/code. For integration spikes where you want to explore an API without any local setup, the browser option puts it in the same category as Bolt.new. Pro starts at $20/month.

Using OpenAI Codex for integration scaffolding

Codex is OpenAI's agentic coding tool, available through the CLI, a desktop app, VS Code and JetBrains extensions, and directly inside ChatGPT. It works differently from both Cursor and Claude Code: when you assign a task, Codex spins up an isolated cloud sandbox preloaded with your repository, reads the codebase, makes changes, runs tests, and returns a diff with terminal logs you can trace step by step. Tasks typically take between 1 and 30 minutes depending on complexity.

For the QuickBooks integration, you'd push your project (with the same npm packages and .env setup from the Cursor walkthrough) to a GitHub repo, then assign the task in Codex:

Build a QuickBooks Online OAuth 2.0 integration in this repo.
Create an Express server with /connect, /callback, and /refresh
routes using the intuit-oauth package. Add an /invoices endpoint
that fetches all invoices using node-quickbooks with pagination
and token expiration checks. Return a clean JSON response with
invoiceNumber, customerName, totalAmount, dueDate, and status.
Read credentials from .env. Store tokens in memory for now.

Codex clones the repo into its sandbox, scaffolds the files, and runs the server to verify it starts cleanly. When the task completes, you get a diff showing every change and the terminal output from the test run. You can review it, request revisions, or open a pull request directly.

One thing to know for integration work: Codex's sandbox originally had no internet access (a security decision), though OpenAI has since made it optional. If internet is disabled, Codex can scaffold and test the code structure, but you won't be able to test the live OAuth flow against QuickBooks sandbox until you pull the code locally or deploy it. For the scaffolding phase, this doesn't matter. For end-to-end testing, you'll run that step outside Codex.

The practical niche compared to Claude Code and Cursor: Codex excels at background task batching. You can queue multiple integration tasks in parallel (scaffold the QuickBooks module, write tests for the OAuth flow, generate API documentation) and review the results when they're done. Included with ChatGPT plans; Plus at $20/month.

Building the same thing in Lovable

Lovable works at a higher abstraction level. Instead of writing modules, you describe the application:

Build a web app where users can connect their QuickBooks Online
account. Include:
- A "Connect to QuickBooks" button that starts OAuth 2.0 auth
- After connecting, show a dashboard table with their invoices:
  invoice number, customer name, total amount, due date, and status
- Use Supabase for storing OAuth tokens per user
- Include a loading state while invoices are being fetched

Lovable generates a full UI within minutes: a landing page, the connect button, a callback handler, and a styled invoice table with loading states. The front-end quality is genuinely impressive for the time invested.

Where you'll need to do additional prompting:

The OAuth token exchange has to happen server-side (QuickBooks requires it), so you'll need to configure a Supabase Edge Function or similar backend handler. Prompt Lovable to set this up: "Add a Supabase Edge Function that handles the OAuth callback, exchanges the auth code for tokens, and stores them in a Supabase table with row-level security enabled."

Expect two or three follow-up prompts to get the OAuth flow fully working. One tester using Lovable across multiple platforms described this as the "fix and break" cycle: fixing one component sometimes breaks another. The solution is to keep your prompts focused on one piece at a time rather than asking for sweeping changes.

Lovable's strength here is the visual demo. If you need to show stakeholders what a QuickBooks integration looks like inside your product, you can have a clickable prototype with real data in about an hour. The generated code exports to GitHub, so a developer can take it from there.

Rapid integration spikes with Bolt.new

Bolt.new sits between Lovable's full-app generation and Cursor's code-level control. For integration work, it's best suited for quick technical spikes: can we connect to this API, what does the data look like, will the response structure match our schema?

Create a React app with an Express backend that authenticates with
QuickBooks Online using OAuth 2.0 and displays invoices in a
sortable, filterable table. Use environment variables for API
credentials. Store tokens in memory.

Bolt generates both layers in a single browser session and deploys with one click. The advantage over Cursor is zero local setup. The advantage over Lovable is more visibility into the backend code. You can inspect the Express routes, see exactly how the OAuth flow is wired, and test the API calls directly.

For integration spikes during sprint planning, Bolt is the fastest way to answer questions like "does QuickBooks return line-item detail on invoices?" or "what pagination format does their API use?" You explore the API surface, validate your assumptions, and throw the code away before committing engineering time to a full build. (For a deeper look at what the QuickBooks API actually exposes and how its new tiered pricing model affects integration costs, that's worth reading before you build.)

Where vibe-coded integrations deliver value

Prototyping and validation is the clearest win. A working Cursor prototype that pulls live data from QuickBooks sandbox turns a roadmap discussion from theoretical to concrete in an afternoon. Stakeholders see real invoice data in a UI that resembles your product. That's a better artifact than a spec document.

Internal tools are a solid fit too. A reporting dashboard that pulls data from your company's own Salesforce instance for an internal team of five users doesn't need the same reliability and security standards as a customer-facing integration. If the token refresh breaks, someone on the team re-prompts and patches it.

Integration spike work is where experienced engineering teams get the most from vibe coding. Two hours in Cursor exploring an API's data model, pagination, and rate limits generates better technical specs than reading documentation alone. The throwaway code becomes a reference artifact for the production build.

The security problem nobody prompts for

When you build an API integration, your application handles sensitive data: financial records from QuickBooks, employee PII from HRIS systems, customer records from CRMs. The security requirements around this data are non-trivial, and vibe coding tools don't generate them unless you explicitly ask for each one.

Vibe-coded integrations commonly store OAuth tokens in plaintext, in a single database table, with no encryption at rest. For a prototype, this is fine. For a production integration handling your customers' accounting data, it's a compliance failure. SOC 2 requires encryption of credentials at rest and in transit, access logging, and the ability to audit who accessed which tokens and when. GDPR requires data processing documentation and, for EU customers, data residency controls.

An analysis of AI-generated code across 470 GitHub pull requests found that AI-produced code was 2.74x more prone to security vulnerabilities than human-written code. The most common problems in integration contexts were hardcoded API keys, missing authorization checks, and references to API endpoints from outdated training data. These are the kinds of vulnerabilities that pass a "does it run?" test but fail a security review.

There's also the question of where your customers' data flows. When you build a custom integration, your infrastructure is part of the data path. Every invoice that passes from QuickBooks through your app is data you're responsible for under your customers' compliance frameworks. If your vibe-coded integration doesn't encrypt data in transit, doesn't sanitize error logs (which often contain request payloads), and doesn't implement proper access controls, you've created a liability that grows with every customer who connects their account.

This is one area where infrastructure providers offer a structural advantage. Platforms like Apideck operate on a pass-through architecture with zero data storage: API requests go directly from your application to the source system and back without caching payloads or storing customer data on any intermediate server. That architectural choice means there's no third-party database of your customer data to worry about, which reduces your SOC 2 audit scope and keeps your compliance footprint small. For categories like accounting and finance, where a single leaked dataset can trigger regulatory investigations, the difference between "we store tokens and pass data through our servers" and "we don't touch your customers' data" is often the difference between passing and failing a security review.

What changes after the demo

The transition from prototype to production is where the cost model shifts. A vibe-coded QuickBooks integration takes an afternoon. Supporting that same integration for paying customers over two years involves a different set of problems.

Third-party APIs change on their own schedule. QuickBooks Online ships minor version updates that introduce new required fields. Xero modifies rate limiting rules. Salesforce retires API versions annually. Each change requires updating your integration code, testing against the new behavior, and deploying without breaking existing connections. A vibe-coded integration typically has minimal test coverage, no monitoring to detect provider-side changes, and no documentation beyond a chat history someone might have closed.

The maintenance math across multiple industry analyses is consistent. A single production-grade API integration takes 40 to 80 engineering hours to build. Annual maintenance adds roughly 120 hours per integration covering API updates, bug fixes, and support tickets. At a blended rate of $100/hour, that's about $16,000 per integration in year one. Five accounting integrations (QuickBooks, Xero, NetSuite, Sage, FreshBooks) puts you at $80,000+ in year one, and cumulative maintenance costs often exceed the original build cost by year three.

Vibe coding compresses the initial build. But the initial build was never the expensive phase. As Paul Battisson put it in Salesforce Ben's 2026 predictions piece: "If you can build things faster, that doesn't necessarily mean you're going to build better things faster. It just means you're going to make more, faster."

Andrej Karpathy, who coined "vibe coding" in February 2025, was candid about this at a 2026 Sequoia talk: AI-written code is "bloaty" and "brittle," and developers "still have to be in charge of the aesthetics, the judgment, the taste, and a little bit of oversight." Forrester's 2026 research predicts that 75% of technology decision-makers will face moderate to severe technical debt by year-end, driven in part by AI-generated code running in production. A study of 8.1 million pull requests found that technical debt increases 30 to 41% after teams adopt AI coding tools.

When integration infrastructure makes more sense

If your product needs to support multiple platforms in the same category, building and maintaining each connection yourself (whether by hand or by prompt) creates a permanent engineering tax. Unified API providers exist to absorb that tax.

The concept is straightforward: instead of separate integrations with QuickBooks, Xero, NetSuite, Sage, and FreshBooks, you integrate once with a standardized API that handles the connections for you. The provider manages OAuth flows for each platform, migrates your integration when providers push API updates, and normalizes data models so an invoice from QuickBooks looks structurally identical to one from Xero.

The economics work because integration maintenance is the expensive part, and that's exactly what a unified API eliminates. If five accounting integrations cost your team $80,000+ in year one and compound from there, a unified API subscription that costs a fraction of that while covering ongoing maintenance is a clear trade. Your engineers ship product features instead of debugging token refresh logic for the third time this quarter.

This doesn't fit every case. One simple webhook to Slack doesn't need a platform. If your product's core value depends on a proprietary, deep integration with a single system, you want full control. But when your customers need to connect their accounting software, their CRM, their HRIS, and your team is spending sprint capacity on integration maintenance rather than core product work, the choice becomes an engineering resource allocation question with a known answer.

Matching the approach to the job

Vibe coding produces functional integration prototypes, useful spikes, and workable internal tools. For those use cases, Cursor, Claude Code, and Codex give you the most control over the output (Cursor through visual diffs, Claude Code and Codex through autonomous execution, with Codex adding parallel task batching), Lovable gives you the fastest visual demo, and Bolt.new gives you the quickest full-stack experiment.

For customer-facing integrations at scale, the initial build was always the cheapest phase. What costs real money is the second year: the API deprecations, the authentication edge cases, the support ticket from a customer whose invoice sync has been silently dropping records. The vibe-coded prototype proved the integration was feasible. That was its job, and it did it well. The question is what comes next.