Email, AI features and PDFs in your app

How an app on LazyFrog sends email through your own provider, uses AI features through the AI gateway, and makes PDFs.

Email: a paid-plan feature (on Free the app's sends are refused: "Sending email from your app needs a paid plan and your own domain: upgrade in Account › Billing"; form notifications work on every plan). The app's mail goes out through the owner's own email provider, which the owner connects at https://app.lazyfrog.dev/account/email (Account › Email: they choose the provider, paste its key there and set the sender, an address on their own domain that the provider has verified; a project can have its own). You never see or handle the key; don't ask for it in the chat, and don't put a provider's key in secrets for this. Check email status before building around email (a booking site's confirmations, reminders): while it says not connected, tell the user in one line that the app's emails start once they connect their email provider there, and keep each send's result so it can be resent. On a project without its own domain (a free lazyfrog.app address), emailing customers needs the user's own domain at their provider; until then, use the page's own confirmation and form notifications (Forms), which LazyFrog sends itself. Meanwhile, a sole trader can reach customers from their own phone: a one-tap WhatsApp (https://wa.me/<number>?text=…) or text (sms:<number>?body=…) link on the owner's page, with the customer's private booking link in it. The app needs no setup: POST $LAZYFROG_MAIL_URL/send (http://mail.local; LAZYFROG_MAIL_URL is the one to use: platform variables are LAZYFROG_-prefixed, and MAIL_URL is left to the app's own mailer) with JSON {to: [...], subject, text and/or html, reply_to?, from_name?, attachments?: [{filename, content (base64)}]}, or SMTP to $SMTP_HOST:$SMTP_PORT (localhost:2525, no TLS, any credentials, so Nodemailer and smtplib work as they are). It goes out from the sender the owner set (email status), with the app's from_name if it gives one; replies go to the owner unless email reply_mode changes that, and a message's reply_to (a form visitor's address) wins. to: ["owner"] reaches the project's owner (no need to store their address). From the preview, mail goes only to the account's own people; customers get it from the live site. Transactional mail only (sign-in links, receipts, booking confirmations; newsletters and marketing are refused, through the owner's provider too: for a newsletter, the owner's own account at a newsletter service (Buttondown, MailerLite, Brevo and others have free tiers, and do the confirm-by-email, the unsubscribe link and the list), with its sign-up form or its subscribe address embedded on the site and their account name kept in the app's settings, never a list of addresses kept here); at most 50 recipients a message, and 60 emails a minute and 600 an hour across the account, which protects the owner's provider account from a loop. A refusal answers {"error": {"code", "message", ...}}: 402 plan_limit with limit: "app_email" (a Free account), reason: "not_connected" (no provider yet) or "provider_error" (the provider refused or couldn't be reached; its words are in the message and in email status, such as a domain the provider hasn't verified). A failed send isn't retried later: record each send's result with the row it belongs to and offer a resend.
A message from the owner to one customer (a reminder, an answer, a change of time) is not the app's mail and not yours to send: message request puts the exact text in front of the owner, who approves it in the portal; LazyFrog sends it through the owner's email provider (see "Two jobs"), so it needs one connected.
AI inside the app (a chatbot, summaries: not you, the AI building it): ask which provider they use first (or suggest one with a cheap small model). Each environment has its own key: the owner pastes it at https://app.lazyfrog.dev/p/<slug>/ai (Project › AI; the Live site card is the one visitors use), so it never passes through the chat; ai key_set (with env: "production" for the live site) is for a key they paste to you anyway. Tell them to set a spend limit at the provider too. The app calls $LAZYFROG_AI_URL/openai/v1 (OpenAI SDK baseURL), $LAZYFROG_AI_URL/anthropic (Anthropic SDK) or $LAZYFROG_AI_URL/compatible (OpenRouter, Groq and other OpenAI-compatible providers) with $LAZYFROG_AI_KEY as the API key. The real key never enters the app. Each environment has a monthly cap (default $5, ai cap_set); at the cap requests fail with a clear error, so handle errors in the UI: a failure answers {"error": {"code", "message", ...}}: 409 conflict with reason: "no_key" (no key for this environment), 402 plan_limit with limit: "ai_spend_cap", or the provider's own status and body. Show visitors a short "the assistant is resting, call us" line, not the raw error.
An AI product (usage pricing, many customers): the gateway's cap is the project's, shared by all its customers: meter tokens per customer yourself (from each response's usage) and stop at their quota before the gateway's cap stops everyone. Its max_tokens clamp applies when you send one, so always send one; a prompt the cap can't pay for is refused with 402.
Search and answers over documents (RAG): embed with the provider's embeddings model (text-embedding-3-small through /openai/v1/embeddings; Anthropic has no embeddings endpoint: Voyage through compatible, or OpenAI's); chunk within pages so every citation has one, and record the embedder on each row to re-index when it changes. pgvector with an HNSW index: build it in a migration with SET maintenance_work_mem = '512MB' (the default 128 MB takes minutes over 50k chunks), and query a tenant's rows with SET LOCAL hnsw.iterative_scan = relaxed_order and hnsw.ef_search = 100, or filtered results come back short. About 8 KB a chunk at 1536 dimensions, as much again for the index: a 2 GB sandbox holds 100–150k chunks; beyond that, halfvec or 512 dimensions. Treat documents' text as data, never instructions.
Confidential documents (a law firm's, a clinic's): say where they go. The files and the database stay in the project (Germany); each AI request goes to the provider, which is the user's sub-processor for every customer, and keeps API inputs for up to 30 days unless a zero-retention agreement says otherwise (OpenAI's EU endpoint, eu.api.openai.com, works through compatible). Put a preview password on before real documents go in, and say that what you query or screenshot passes through you.
A chat box on a site (answers about the business): the AI runs in a service, never the page (a static site adds a small api service, which counts toward the plan's services). Answer only from the site's own facts (put them in the system prompt), treat what visitors type as questions and never as instructions, reply in plain text (no HTML from the model), keep max_tokens about 300 and the last ~6 turns, use a cheap model, and limit each visitor by X-Lazyfrog-Client-Ip (say "try again in a minute" past it). On Free the LazyFrog badge sits bottom right of the preview: put the chat button bottom left.
PDFs and images: POST $RENDER_URL/pdf (http://render.local) with {"html": "..."} or {"path": "/invoice/42"} (a page of the app), optional paper (A4, Letter…) and landscape; /png with width/height for share cards. The answer is the file. It fetches the app directly, so routing.json (auth, rewrites, headers) doesn't apply: never pass a path a visitor chose. Fonts and images from other sites are blocked: serve them from the app (look apply stores the look's fonts in the project); html loads the app's own fonts and images by relative URL (/fonts/...), and the site's own addresses reach the app too. Limits: 5 MB of HTML, 20 s for the page to load, about 200 A4 pages; one table of more than about 10,000 rows can't print at once (split it into tables of 1,000). Papers A3, A4, A5, Letter, Legal and Tabloid, or CSS @page { size: 100mm 150mm }. The first render after a quiet spell takes up to 20 s: render from a worker, not while a visitor waits.

Email, AI and PDFs for the app