Introduction

Integration from a local-only app

Your product already works on a single device: user data lives on that phone, tablet, or browser, and there is no shared account system. This page shows how to add secureFlows — mainly by giving an AI coding tool the right prompts — so people can sign in, keep their data across devices, and stay private from each other.

Who this is for

Use this guide when all of the following are true:

The app already stores meaningful user data on the device (web and/or mobile).
There are no shared accounts or a central user database today.
You want users to sign in with secureFlows and keep their data there going forward.

Brand-new app with no existing local data? Use the Integration Walkthrough instead. Already using Auth0, Cognito, or your own user table? That is a different migration — this page assumes the device was the only place durable data lived.

Before the prompts: create a workspace and register an application in Workspace Management (you will need the workspace name and application ID). The walkthrough covers that setup if you have not done it yet.

What changes

	Today (local-only)	After secureFlows
Who the user is	Whoever is using this device or install	A signed-in person (secureFlows shows the sign-in screen; you never handle passwords)
Where data lives	Only on that device — wipe or reinstall and it is gone	In secureFlows as the app’s main user database (kept by default)
Other devices	No way to continue on another phone, tablet, or laptop	Same person signs in elsewhere and sees their data
Your product UI	Everything is local features only	Still your screens and features — secureFlows adds sign-in and private storage underneath

One idea to keep

One place for lasting data

After you switch, treat secureFlows as the real home for user content. The device can still hold temporary things (drafts, caches, offline queues), but not a second permanent copy that can disagree with what is already saved in the cloud.

Integration prompts

Paste the block below into your AI coding tool (Cursor, Claude Code, Lovable, Base44, and similar). Replace the placeholders with your workspace name and application ID from the console. Keep the Why line — it tells the tool this is an intentional architecture change, not a conflict with “local-only” notes in the old project.

Prompt A — add sign-in and move lasting storage to secureFlows

This app already stores user data only on the device (no shared accounts).

Use secureFlows for auth and data storage (read https://www.secure-flows.com/ai/secureflows-integration/SKILL.md).
Use: workspace = <YOUR_WORKSPACE>, appId = <YOUR_APP_ID>
Why: moving from local-only on-device storage to multi-user secureFlows.

Add secureFlows hosted login (Continue with secureFlows / Sign out).
After sign-in, save and load this app’s lasting user data through secureFlows — not as a second permanent copy on the device.
Keep describing the product features as they are today: <brief description of what the app does and what it stores>.

Run this after the workspace and application exist. If the tool asks for API keys or passwords, something is wrong — secureFlows integrations never need those from you.

Migrating existing local data

People who already used the app on a device still have old data sitting locally. Use a second prompt after Prompt A works (sign-in and cloud save/load feel correct for a new user).

Prompt B — import this device’s old data once

After a user signs in with secureFlows for the first time on a device that still has old local data from before accounts existed:

1. If their secureFlows record is empty, import the old on-device data into secureFlows once, then stop treating that local copy as the source of truth.
2. If they already have data in secureFlows (e.g. they signed in on another device first), do NOT overwrite the cloud copy with old local leftovers. Keep the cloud data. Optionally offer a clear “Import this device’s old data” choice only when the user asks for it.
3. Never re-import on every launch.

Use the same secureFlows workspace/appId and SKILL.md as before.
The local data looks like: <short description — e.g. “name and age in localStorage” or “notes list in SQLite”>.

Adjusting the prompts for your app

Workspace and appId — must match the console exactly (same spelling and casing).
“What the app does / what it stores” — name the real fields or screens (e.g. profile, shopping list, workout log). The more concrete this is, the better the tool maps old local keys to secureFlows.
Web vs mobile — say so in one sentence if it is not obvious from the project (“This is a Flutter iOS/Android app” or “This is a Vite React web app”). You do not need to describe login protocols yourself.
Guest / unsigned use — if you still want a guest mode, say whether guests may keep temporary local drafts only, or must sign in before anything lasting is saved.
Staging — when testing against staging, append the same line as in the walkthrough: replace every www.secure-flows.com with your staging host.

Where to go next

Setup and plain-language sign-in story: Integration Walkthrough. More questions: Q&A. The reference your AI tool reads: SKILL.md.

Advanced (optional)

For engineers who want the mechanical checklist behind those prompts. Most teams can skip this and stay with Prompts A and B.

Recommended sequence

Provision workspace + application (redirect URI = app origin + /callback).
Add hosted login; store the session token only in short-lived client storage (web: sessionStorage, never localStorage).
Route new lasting writes through secureFlows once the user is signed in.
One-time import of on-device data after first sign-in on that device (Prompt B).
Verify: user A saves → sign out → user B must not see A’s data.
Stop treating on-device keys as authoritative; optionally delete migrated local copies.

Migration details

Prefer importing only when the cloud record is empty. If cloud data already exists, keep it unless the user explicitly chooses to import this device’s leftovers. Mark migration done so it never runs again on every launch. Stay within plan payload size limits; large files belong in object storage with URLs in the payload.

Pitfalls

Do not send a homemade userId in request bodies — identity comes from the session token.
HTTP 410 means sign in again, not “data deleted.”
On mid-flow signed-out (e.g. Save), clear token and signed-in UI state so Sign out does not appear stuck.
Avoid dual-writing forever to local + secureFlows for the same lasting fields.

Wire-level HTTP: Integration Quickstart.