Add Login, Stripe and Integrations to an Emergent App

This post is for intermediate builders. You have an Emergent app working in preview, maybe already live, and now you want user accounts, payments or email. I will cover how each one is set up in Emergent today, where your API keys should live, and the checks I would never skip before real people sign up.

The one rule: never paste real keys into chat

Emergent's own security docs are clear on this. Chat content is sent to the AI provider, so a secret key pasted into a prompt has left your control. If you have already done it, rotate the key with the provider (create a new one and delete the old one).

Here is how keys are meant to work in Emergent:

• The agent adds the key name to your app's .env file. You add the value.
• For the live app, values go in Preview > Manage > Secrets > Custom keys. Save, then Re-publish.
• After your first publish, preview and production secrets are separate. Changing one does not change the other.
• Anyone with publish access to the project can reveal secret values, so keep project access tight.

You will see older tutorials (including some on Emergent's own site) that paste Stripe keys into a prompt. The current docs say not to. Follow the docs.

Adding login and user accounts

Login is not included by default. You ask for it in chat. Emergent Auth gives you two options with no setup and no extra billing:

• Email and password. Passwords are stored hashed.
• Google sign-in. No Google Cloud Console setup needed. You can supply your own Google client ID and secret later if you want custom branding on the consent screen or extra Google scopes.

If you need a fully custom login screen or already use a provider, the agent can integrate Auth0, Clerk, Firebase Auth or Supabase Auth instead.

A prompt I would use:

Add user accounts with Emergent Auth: email and password, plus Google sign-in.

Done when:
- New users can sign up and land on their own dashboard
- The dashboard, settings and all project pages require login
- Visitors who are not logged in are sent to the login page
- Each user only ever sees records they created
- There is a log out button in the header

Add a displayName field to users now.
Do not change the design of existing pages.

Two things in that prompt are deliberate. "Each user only ever sees records they created" is the line that matters most, and agents do not always assume it. And adding user fields now follows Emergent's own advice to add extra user fields before your first publish.

Adding Stripe payments

Stripe is the default payment option. Money goes from Stripe to your bank, and Emergent's docs say it takes no cut. You pay your Emergent plan and Stripe's normal fees. Razorpay and PayPal are available in some markets, and the agent can tell you which fits your country.

You have two ways to set it up:

1. Managed sandbox. Emergent manages the Stripe keys for you. You claim the sandbox in Preview > Manage > Payments, finish Stripe's registration and identity checks, and install the Emergent app in Stripe. Test payments will not work in preview until this is done.
2. Your own Stripe account. The project owner unlinks the sandbox first. Test keys go in the project's .env. Live keys go in Custom keys under Secrets.

One important exception: Stripe is not available for mobile-only (Expo) projects. In-app purchases there use RevenueCat, and the app stores take their own fees.

A payments prompt:

Add Stripe subscriptions using the managed sandbox.

Plans:
- Free: up to 3 projects
- Pro: $12 per month, unlimited projects

Done when:
- A pricing page shows both plans with an upgrade button
- Checkout uses Stripe in test mode
- After a successful payment, a Stripe webhook marks the user as Pro in the database
- Free users who hit 3 projects see an upgrade prompt instead of an error
- Users can cancel, and access drops back to Free at the end of the period

Do not switch to live mode. I will do that myself.

I name the webhook on purpose. Emergent's payments docs say that if a payment succeeds but the user gets no access, webhooks are the likely cause. Asking for it up front saves a round of debugging.

Email, SMS and other services

Emergent has tested setup recipes it calls playbooks. You find them in Preview > Manage > Connectors. Current playbooks include SendGrid and Resend for email, Twilio for SMS, voice and WhatsApp, Slack for posting to a workspace, and Stripe. Some playbooks charge a small per-run credit cost, shown on the tile. Resend works for full-stack web apps but not mobile (Expo) projects.

Anything with a public API can be connected too. You provide the key, the agent writes the code. Without a playbook, expect more back and forth.

If you want AI features inside your app, Emergent's Universal LLM Key lets your app call GPT, Claude and Gemini models without separate accounts. Those calls are billed to your Emergent credits, so put a usage limit in your app or you could see a surprise on the usage screen.

When a user signs up, send a welcome email using the Resend playbook.
Tell me which key name to add and where I find the value in Resend.
Do not send any other emails yet.

What to check yourself before real users

The agent tests in preview. It cannot see your live app, and it cannot see your production secret values. So the final checks are yours. This is the list I run:

Accounts

• Sign up as two different test users in the live app. Confirm neither can see the other's data, including by changing an ID in the URL.
• Log out and try to open a dashboard URL directly. You should be sent to login.
• Test password reset if you added one.

Payments

• Run a test checkout with a success card and a decline card.
• Confirm the sale shows up in your database and that access changes after payment.
• Re-check every price. A misplaced decimal charges real people the wrong amount.
• When you switch to live, confirm the live keys are in production Custom keys, then Re-publish. Run one small real payment and refund it.

Secrets and data

• Search the code for anything that looks like a key or password. Nothing should be hard-coded.
• Keep sensitive data out of the front end. Live apps are public by URL, so anything in the browser code can be read.
• Decide whether the app should stay open to the public before launch, or sit behind login.

Emergent's Keep it safe page has the full pre-launch list. Read it once, then turn it into your own checklist.

Where to go next

The build specs in /recipes are scoped feature specs you can paste into Emergent and extend with checks like the ones above. If you want someone to look over your app before real users arrive, bring it to office hours or a cohort and we can look at it together.