Handover
What happens to the accounts Squiid provisions when you leave. Transfer where the provider supports it, export everywhere else, provider by provider.
Short answer. Where the provider supports transferring ownership, the account or project becomes yours and Squiid steps out. That covers Supabase, Neon and Vercel as of their documentation. Everywhere else, leaving is an export plus written steps to re-create the resource in your own account. Usage-metered APIs have nothing to move, and connect-class services such as Stripe and GitHub were your own accounts the whole time.
This page exists because "we can hand the account over" is only true for some providers, and a claim that is true for some providers is a false claim on a pricing page. Every service page in the catalogue carries the same answer for that one service, in its At a glance panel and an "If you leave" note.
Provider by provider
| Provider | What Squiid creates | Transfer | How you leave |
|---|---|---|---|
| Supabase | One organization per tenant, with your projects inside it. | Yes | We invite you as Owner of that organization and remove ourselves. Project transfer between organizations also exists in the dashboard. |
| Neon | One project per tenant. | Yes | Neon's API supports moving a project between organizations, so the project lands in yours intact. |
| Vercel | One project per tenant inside a Squiid team. | Yes | Transferring a project between teams is a supported flow, started by a member of both. Your own team carries the seats afterwards. |
| Cloudflare (R2, Workers, KV, D1) | A bucket, Worker or namespace inside Squiid's account. | No | Export. R2 objects copy out with S3-compatible tooling, Workers are redeployed from your source, KV and D1 are dumped and re-created. |
| Twilio | One subaccount per tenant. | Partial | Subaccounts cannot be moved to another parent. Phone numbers port to your own Twilio account through Twilio support; messaging services and logs are re-created. |
| Resend and other email senders | A sending domain and keys inside Squiid's team. | No | You re-verify the domain in your own account with the same DNS records and re-create templates. Minutes of work, not a migration. |
| Upstash | One database per tenant. | No | Back up and restore into your own Upstash account. |
| Pinecone, Qdrant and other vector stores | One index per tenant. | No | Export the vectors and index settings, re-import into an index in your own account. |
| OpenAI, Anthropic, Gemini and every metered API | Nothing. The API is usage-metered. | n/a | Nothing to move. Create your own key and point the client at it. Squiid does not store your prompts or completions. |
| Stripe, GitHub, Slack and the rest of the connect catalogue | Nothing. The account was already yours. | Already yours | Squiid only holds an authorised connection. Revoke it and nothing is lost. |
The four rules
- You can always leave. Squiid never owns your code, your data model or your domain, and the gateway speaks each provider's own API rather than a proprietary abstraction, so the client-side change is a base URL and the provider keys going back into your environment.
- Transfer is claimed only where the provider supports it. Today that means Supabase organizations, Neon projects and Vercel projects. If a provider adds an ownership transfer, it moves into the transfer column here and in the catalogue, not before.
- Everywhere else it is an export. You get the data and the documented steps to stand the resource back up in your own account. We do not describe that as a handover, because it is not one.
- Metered APIs have nothing to move, and connect services were always yours. Leaving OpenAI or Anthropic means creating your own key. Leaving a Stripe or GitHub connection means revoking a token Squiid held against an account you already owned.
What this means before Phase 2 ships
Provisioning is being built so that each tenant gets its own ownership unit at the provider, an organization, project, team or subaccount, rather than a resource buried inside one shared Squiid account. That is the decision that makes a transfer possible later instead of impossible, and it is cheap now and expensive to retrofit. Where the provider has no such unit, the export path is documented per service instead.
Questions people ask
Can Squiid hand over the account it created for me?
For some providers, yes. Supabase, Neon and Vercel support transferring ownership of an organization, project or team, as of their documentation, and those move to you. For the rest, handover is an export: we give you the data and the documented steps to re-create the resource in your own account. We would rather say that than claim a transfer that does not exist.
What does export actually involve?
A database dump you restore, a bucket you copy with S3-compatible tooling, an index you re-import, or an app you redeploy from your own source. Your code, your schema and your domain were never ours, so what moves is data and configuration, not a rewrite. The per-service page for every provider in the catalogue says which of these applies.
Why does Cloudflare say no transfer?
Because Cloudflare does not offer an account transfer for the resources Squiid creates inside its account. R2 buckets, Workers, KV namespaces and D1 databases are exported and re-created in your own Cloudflare account instead. Twilio subaccounts have the same limitation, which is why phone numbers are ported through Twilio support rather than handed over.
What happens to my data if I stop paying?
Metered calls pause and nothing is deleted. Subscription-priced services are debited on renewal and pause if the balance is short. Your data stays at the provider while the resource is live, and you can start a handover at any point. See spend controls for what pausing looks like.
Leaving should be boring.
Transfer where the provider supports it, a documented export everywhere else, and nothing to move for metered APIs.