Add AI Pass to a Vercel Next.js app without moving your hosting

Adding AI Pass to a Next.js application does not require moving the application off Vercel. Keep the deployment, domain, database, and account system you already operate. Add a way for a user to authorize and fund an AI action.

The architectural decision is where that action belongs. A browser feature and a server-only workflow should not receive the same integration simply because both have a Generate button.

This design uses a hypothetical release-note editor: users select completed tickets, draft a release announcement, then edit and publish it through the existing app. The deliverable is an architecture and acceptance plan, not an untested SDK snippet disguised as working software.

Draw the two request paths

For a browser SDK integration, the page owns the visible AI interaction. The user selects ticket text, connects AI Pass when needed, and requests a draft through the supported SDK flow. The Next.js application continues to store projects and enforce access to those projects. Consult the SDK documentation for the current loading and invocation contract.

For backend OAuth, a Next.js backend route handles the authorized model request. Runtime tokens belong to the corresponding local user and require protected storage. The browser submits a permitted operation, not an arbitrary instruction to spend from whichever wallet the server can access. Use the REST documentation together with the backend reference linked from the integration skill.

Prefer the browser path when the browser already holds the intended inputs and your security policy allows it. Choose the backend when private prompts, server-only ticket data, or token-custody requirements demand that boundary. The shorter code path is not automatically the right one.

Keep rendering separate from spending

Next.js rendering should never be the trigger for a paid generation. Opening a page, refreshing it, or re-rendering a component must not create release notes again.

Make "Generate release draft" an explicit action. Snapshot the selected tickets and output preferences at submission, then associate the result with that snapshot. If a user edits the selection while a request is pending, label the returned draft with the original selection rather than pretending it reflects the new one.

Treat the AI response as user-specific data. Do not place private ticket content or generated drafts into a shared cache. A public release page can have its own publication and caching policy after an authorized editor approves the text.

Plan localhost, preview, and production

OAuth callback configuration deserves a place in the deployment checklist. Record the exact localhost, chosen preview, and production destinations required by your integration. Browser SDK and backend OAuth paths have different callback shapes; follow their current references rather than deriving URLs from memory.

The official setup workflow keeps callbacks for one project on one client. A new preview address is not a reason to manufacture another application identity. Add approved destinations through the supported setup process, and use a stable preview target where practical.

Keep public project metadata separate from setup recovery secrets and runtime credentials. Never place a secret in a browser-exposed environment variable. Review the actual generated bundle and deployment settings, not just a variable's reassuring name.

Write acceptance criteria before implementation

The release-note feature should pass these checks:

• An existing user can open and edit a project without connecting AI Pass.
• Only tickets the user can access enter the request.
• Pressing Generate once creates one model request, even if the interface re-renders.
• Cancelling connection preserves the selected tickets and manual edits.
• An AI Pass-funded action does not also deduct existing app credits.
• A completed draft remains editable without another model call.
• Switching local accounts cannot reuse the previous person's wallet accidentally.
• Publishing still requires the app's existing permission and explicit publishing action.

The authentication and billing preservation guide explains why wallet funding must not bypass local entitlements.

Also test the deployment boundary: the intended preview can connect, an unapproved destination cannot, and production has no dependency on a developer's localhost session. Inspect logs for token leakage and private ticket text before sharing a preview with colleagues.

Define a truthful release gate

A successful build proves that the application compiles. It does not prove wallet authorization, charging behavior, or the rendered model response. Those need a separately approved live request through the actual interface, followed by inspection of the request and result.

If spending has not been authorized, finish the non-spending checks and mark live verification pending. Do not fill the gap with a mocked response labeled as a successful integration.

The finished change should be small enough to review: a connection boundary, a funding choice, one request path, and documented failure behavior. Your Vercel application stays where it is. AI Pass supplies an additional user-funded route rather than a new hosting requirement.