Lovable

Ship Lovable apps with real email, verification, and browser handoff.

Use KeyID for contact forms, agent inboxes, registration emails, and OTP/TOTP. When the flow leaves your app and enters a third-party site, hand the browser step to Playwright or a KeyID-backed MCP agent.

Verification flows Open MCP hub Replit guide
Lovable prompt pack SDK + MCP handoff Email + verification Playwright-ready

Prompts and setup

Let Lovable generate the app surface. Keep KeyID in the app for email and hand browser-heavy signup flows to MCP or Playwright when needed.

Lovable prompt

Prompt Lovable to wire KeyID

Add a contact form and signup assistant using KeyID.
Install @keyid/sdk.
Provision a KeyID identity on first run.
Use it for outbound email, inbound inbox reads, and verification state.
If the flow needs a live third-party browser signup, hand the browser step to Playwright or a KeyID MCP agent and keep secrets in KeyID.

SDK

App-side TypeScript snippet

import { KeyID } from '@keyid/sdk';

const agent = new KeyID();
const identity = await agent.provision();

await agent.send('ops@example.com', 'New signup lead', JSON.stringify({
  email: identity.email,
  source: 'lovable'
}, null, 2));

Browser automation

When to hand off to MCP or Playwright

Use KeyID MCP or Playwright when the job must:
- sign up on a third-party site
- wait for verification email or SMS
- follow verification links or use OTP/TOTP
- store cookies, recovery codes, or final registration state

When to use SDK, MCP, and Playwright

Lovable is strongest when it is building product UI, forms, and app-side actions. That makes the JavaScript SDK the right first layer for outbound mail, inbox reads, and simple automation that stays inside the app.

When the workflow crosses into a third-party signup or login page, KeyID should stay responsible for inbox, phone, OTP/TOTP, and stored secrets while Playwright or a Claude/Cursor MCP client drives the browser.

This split keeps generated app code simple: Lovable owns the app, KeyID owns the durable communications state, and Playwright owns the brittle browser steps only when they are actually required.

Copy-paste prompts

Use these directly in Lovable chat when you want the generated app and the browser-verification handoff to stay coordinated.

  • Add a contact form that provisions a KeyID identity once and uses it for outbound email notifications.
  • Build an inbox page backed by KeyID so the app can show unread verification emails and inbound replies.
  • When a third-party signup requires a browser step, pass the KeyID email into a Playwright flow instead of mocking verification.
  • Store signup cookies or recovery codes with KeyID after the flow finishes.
  • Add an admin view that shows the current KeyID email, unread count, and latest registration state.

Expected handoff sequence

  1. `@keyid/sdk` — provision the app-facing KeyID identity and use it for normal app-side email actions.
  2. `provision_identity` — create the browser-facing identity when a separate MCP or Playwright agent handles the signup.
  3. `wait_for_message` and `get_verification_codes` — retrieve the verification mail or SMS without writing custom polling logic.
  4. `follow_verification_link` or Playwright — use KeyID for safe link follow, or Playwright when the site requires a live browser click path.
  5. `put_secret` and `save_registration` — store cookies, backup codes, and the final registration state for the next session.

Failure and recovery notes

  • If Lovable keeps generating placeholder email logic, replace the mock with a real KeyID provisioning and send/inbox flow.
  • If the signup leaves the app and enters a third-party site, stop trying to do it purely in generated app code and hand the browser steps to Playwright or MCP.
  • If the same Lovable deploy keeps getting a fresh identity, persist KEYID_PUBLIC_KEY and KEYID_PRIVATE_KEY in the deployment environment.