Integrations
The stack we run on, and what you can connect.
code-anything.com writes the backend into every app — data layer, sign-in, payments, row-level security — from a catalogue of vetted, pre-built bricks rather than composing it again each time. Everything else your app needs, from a third-party API to your own domain, is connected the same way: describe it, add the credential, review the code.
Start here
What “integration” means on this platform
Two different things share the word, and the difference decides how much work you do.
Most tools describe an integration as a connector you install from a directory. Here it splits in two. Some services are built in: the code that talks to them is pre-written and vetted, and you reach it simply by asking for the feature that needs it. Describe a paid plan and a real Checkout endpoint, redirect and signed webhook are written in; describe a sign-up form and a table, a session provider, a login form, a route guard and the row-level security to go with them arrive together. You do not open an account or paste a key to get a working preview. Connecting those services to real data, real charges or real mail is a separate step, and you decide whose account it runs on.
Everything else is connect your own. Your app is real, hosted code, so it can talk to anything that speaks HTTP — an API you already pay for, a webhook another system sends you, an OAuth provider, an analytics tool, a domain you own. Those are not managed connectors and we do not pretend otherwise: you bring the endpoint and the credential, and the request code, handlers and signature checks are generated around them and verified before you see them.
The practical result is that the list below is not a limit. The built-in half is what you get for free and never have to think about. The connect-your-own half is the shape of the work when you need something specific — and that work is a sentence and a key, not an afternoon of plumbing.
| Built in | Connect your own | |
|---|---|---|
| Who sets it up | The code goes in with the build, from a catalogue of vetted bricks — you connect the account when it is time to run against the real thing. | You supply the endpoint, the snippet or the DNS record; the code around it is generated. |
| Account required | None to build and preview. Stripe and Resend run on your own account by default; Supabase can run on ours or yours. | Yes — an account with that service, and a credential from it. |
| How you add it | Ask for the feature. Describing a checkout, a login or a reminder email is enough. | Describe the call or the event, then add the credential to the project environment. |
| Where credentials live | Encrypted in the project environment. A brick declares the keys it needs and appends them to .env.example; connecting the provider fills them in. | Encrypted in the project environment, used server-side. |
| What it covers | Data access, auth, payments, routing, backend middleware and row-level security as bricks; plus source control, the sandbox, hosting and the model. | Any HTTP or GraphQL API, inbound webhooks, OAuth providers, analytics tools and your own domain. |
Both halves end up as ordinary code in your repository — see how the platform works for the path a change takes.
Built in
What comes wired in by default
These six sit under every project. There is nothing to sign up for before you have something running: the code that talks to them is written in from vetted bricks as your app needs it, which is why a preview is a working app rather than a mockup.
Supabase
Postgres and auth, pre-wired into every app that needs them.
Postgres and the auth layer on top of it arrive as pre-written code: a vetted data-access brick for server and browser, an auth brick with the session provider, login form and route guard, and a security brick that forces row-level security on every table and indexes what the policies filter on. Tables and migrations are generated as your features need them, and because it is ordinary Postgres you can drop down to SQL whenever a prompt is not the fastest route. Pointing it at a live Supabase project is one explicit connect step — ours or yours.
- Schema and migrations written for you and applied to the project database
- Built-in email and OAuth authentication with row-level security
Stripe
Payments, checkout, and subscriptions wired into your app.
When something in your app needs to charge money, Stripe is scaffolded around it: checkout, one-off payments, subscriptions and the server-side webhook handlers that keep your data in step with billing events. You connect your own Stripe keys, so customers pay you and payouts land in your account — the platform only builds the wiring.
- Checkout and payment flows generated from a description
- Subscriptions, one-time charges, and customer billing
Resend
Transactional email — welcome, reset, and notification mail.
Transactional mail — sign-up confirmations, password resets, receipts and notifications — is sent through Resend from the server, so sending keys never reach the browser. Templates are generated next to the feature that triggers them. This is the one built-in with no brick behind it and no shared account: you add your own Resend key and verify your own domain, so mail arrives from your address with SPF and DKIM in place. Bulk marketing campaigns are out of scope.
- Transactional email for sign-up, reset, and notifications
- Email templates generated alongside your features
GitHub
Your code lives in real repos with reviewed pull requests.
Work lands as branches and pull requests in real repositories rather than as opaque edits. You keep the full git history, read every diff before it merges, and can clone the project or take it elsewhere at any point. It also means the GitHub workflow your team already uses keeps working exactly as it did.
- Changes delivered as branches and reviewed pull requests
- Full git history you own and can clone anytime
Cloudflare
Build sandbox plus global hosting and one-click deploys.
Builds and verification run inside an isolated Cloudflare sandbox, and the finished app is served from Cloudflare’s global edge with a live URL for every project. There is no pipeline to assemble and no server to keep patched — and when you are ready for production you point a custom domain at the same deployment.
- Isolated sandbox for safe builds and verification
- Global edge hosting with a live URL per project
AI models
The models that plan, write, and review your code.
The models are the reasoning layer that ties the rest together: they turn a prompt into a plan, make the change across files, and review the resulting diff before it becomes a pull request. They are also what works out which of the services above a feature implies — that a checkout page means Stripe products and webhooks, or that a sign-up form means auth, a table and a confirmation email. We route to them through our own gateway, and we name them: today Gemini from Google, GLM from Z.ai/Zhipu served via Together.ai, and Mercury from Inception. The set changes as models change.
- Turns natural-language prompts into working code
- Plans multi-step changes across files and the backend
Two of these are your own account by default rather than by request: Stripe, so payouts reach you, and Resend, so mail comes from a domain you verified.
Connect your own
Wire up everything else
Beyond the built-ins, your app can reach almost anything over HTTP. These are connect-it-yourself paths via API, webhooks, OAuth or DNS — not native, managed integrations.
REST & Webhooks
Call any HTTP API and react to incoming webhooks.
The general-purpose path, and the answer to most “can it integrate with…?” questions. Describe the API you want to call or the webhook you need to receive, and the request code, handlers, typed responses and signature checks are written for you. You supply the endpoint and the credential; the wiring is generated around them. It is not a managed connector for a named vendor.
- Call any third-party REST or GraphQL API from your app
- Receive and verify inbound webhooks from other services
OAuth sign-in
Add Google, GitHub, and other social logins.
Email authentication is already there, and social sign-in sits alongside it rather than replacing it. Register an OAuth client with a provider such as Google or GitHub, add the client ID and secret, and the flow is configured through the managed auth layer — sessions and protected routes included.
- Social login with providers like Google and GitHub
- Built on the managed Supabase auth layer
Analytics
Drop in product or web analytics of your choice.
No analytics product is bundled, and none is required. If you already use a web or product analytics tool, its snippet is placed in the app and the custom events you care about are fired at the right points in your features. The vendor relationship — and the data — stay yours.
- Add a web or product analytics snippet to your app
- Track custom events from your features
Custom domains
Point your own domain at the deployed app.
Every project ships with a live URL you can share straight away. To take it to production, add the DNS records for a domain you already own from any registrar; certificates are issued automatically and traffic is served over Cloudflare’s edge. The original project URL keeps working, which makes it a convenient staging address.
- Serve your app from your own domain
- Automatic HTTPS certificates
All product names and logos are property of their respective owners.
The process
How connecting a service actually works
The same five steps whether you are calling an API, receiving a webhook or adding a login provider.
Describe what the service should do
Not “integrate service X”, but what you want to happen: post every new order to our internal webhook, look up addresses through our postcode API, sync a form submission to the CRM we already pay for. The intent is what gets built.
Add the credential to the project environment
Open the project’s Environment and add the key as a secret. Secrets are encrypted and masked — the value is never handed back to the browser once saved. If you already have a .env file, paste the whole thing and every key is imported in one go.
The wiring is generated server-side
Request code, response types, route handlers and — for anything inbound — signature verification. Keys are read on the server, so they are not shipped to the client with the rest of your app.
It is verified in the sandbox before you see it
The change is exercised in an isolated sandbox with your environment applied, and checked with typecheck, tests and a build. Review starts from a green baseline rather than from a guess.
You review, then ship
For a connected repository the change arrives as a pull request you read and merge. For an app built from a prompt, Go Live publishes it to a real URL. Either way, nothing reaches production without you.
Credentials
Where API keys and secrets live
Every project has an environment: an encrypted place for the keys your integrations need, kept out of your repository and off the client.
- Two kinds of entry, following GitHub’s model: secrets are encrypted and masked, and variables are plain values you can see and edit — a base URL or a feature flag, say.
- Stored encrypted against your project, not committed to the repository.
- Applied to the app’s environment when it runs, and read on the server. Anything not explicitly marked as a public key stays off the client.
- Paste an entire .env file to import every key at once — the escape hatch for env files that are gitignored and can never arrive with a git import.
- Values already present in an imported project’s own env files are adopted automatically, so a repo you bring over does not start empty.
- Keys a detected provider needs but that are still missing are surfaced as a warning on the project rather than failing quietly at runtime.
The reason this matters is the failure mode it removes. Keys pasted into source get committed, leak through the browser bundle, and go stale in three places at once. Keeping them in the project environment means the running app is the only thing that ever sees the value, and rotating a key is a single edit rather than a code change and a redeploy.
Preview and production
What happens in preview versus production
One environment powers both, on purpose.
- One environment per project. The same secrets and variables feed the live preview, the test and build runs, and the deployed app — there is no second set of keys to keep in sync or forget.
- The environment is re-applied whenever a fresh container starts and again when you Go Live, so a deploy does not ship against a stale value.
- The preview is the real thing, not a mock: a real Postgres database, real auth, a real mail path and real payment code.
- A practical consequence: build against your provider’s test-mode credentials, then change the value in the environment when you are ready to take real traffic. Because one environment is shared, that switch changes the preview too — make it when you mean it.
Builds and verification run in an isolated Cloudflare sandbox, separate from the deployment your users hit — so a broken build cannot take down a live app. What is shared is the configuration: the same environment, the same managed database, the same code. That is what makes a preview trustworthy. If a payment flow works in the preview, it works because it really ran, not because it was stubbed.
When you are ready, Go Live publishes to a real URL, and a custom domain points production traffic at the same deployment with HTTPS handled for you. The project URL stays available behind it.
Not on the list
If the service you need is not listed here
There is no connector directory to wait on. Almost every integration question resolves to one of three shapes.
Call it over HTTP
If the service has a REST or GraphQL API, your app can use it. Describe the call and the request code, typed responses and error handling are generated around the credential you provide.
Receive its webhooks
If the service pushes events instead, you get a handler for them — verified against the signing secret so a forged request cannot reach your data.
Drop in its snippet
Tools that ship a browser snippet — analytics and similar — are placed in the app, with the custom events you name wired to the features that should fire them.
Worth being straight about the limits. There is no marketplace of pre-built connectors, no vendor-specific dashboards, and no promise that a given service has been tested here. What you get instead is the generic capability — authenticated HTTP calls, verified inbound webhooks, server-side credentials — written as ordinary code in your repository, typechecked and built before it reaches you. If the vendor documents an API, your app can use it; if it does not, no platform can help.
The same applies in the other direction. Because the code is yours in a real GitHub repository, anything you or your team writes by hand sits alongside what the agent generates. Nothing is locked behind a proprietary integration layer.
FAQ
Integration questions, answered
Keep reading
Where to go next
Platform
The end-to-end path: prompt to live preview to Go Live, or repo to sandbox to a reviewed pull request.
Learn moreCapabilities
What the agent can actually build with these services once they are wired in.
Learn moreDocs
Both quickstarts, step by step, plus what the workspace monitors after you ship.
Learn morePricing
Plans and included usage — the backend code is part of every project, not an add-on.
Learn moreThe backend is handled. You just build.
Describe what you want and code-anything.com writes the database, payments and email layers in from vetted bricks, connects whatever else you need, and ships it as a reviewed pull request.