Ranla + Base44

Base44 apps can send email through built-in platform features. Use Ranla when you need your own domain, higher control over deliverability, or the same transactional stack as the rest of your product.

When Base44 built-in email is enough

  • Early prototypes and internal tools
  • Low volume without a custom domain requirement
  • Flows where Base44’s default sender is acceptable

When to add Ranla

  • Branded mail from @yourdomain.com after DNS verify
  • Password reset / auth mail you want on owned transactional infrastructure
  • Webhooks and delivery visibility via Ranla dashboard
  • Consistent API across non-Base44 services (same POST /emails everywhere)

1. Add your API key

  1. Create rnl_… at app.ranla.ai.
  2. In Base44, add a project secret or environment variable (exact UI varies by Base44 project type):
RANLA_API_KEY=rnl_your_key_here

Wire server-side code or automation steps to read that variable — never expose it in client-visible config.

2. Paste this prompt in Base44

Add Ranla for transactional email in this Base44 app (instead of or alongside built-in email).

Docs:
- https://docs.ranla.ai/ai/agent-skill
- https://docs.ranla.ai/openapi.yaml
- https://docs.ranla.ai/builders/base44

Rules:
1. Use RANLA_API_KEY from project secrets — server-side only.
2. POST https://api.ranla.ai/emails with Bearer auth for transactional sends (reset, verify, receipts).
3. Sandbox until domain verify: from "[email protected]", to Ranla account email only.
4. Explain when built-in Base44 email is still fine vs when Ranla is required (custom domain, production volume).
5. Use html/text; verify domain in Ranla before production from addresses.

Link users to https://app.ranla.ai for domain setup.

3. HTTP send

POST https://api.ranla.ai/emails
Authorization: Bearer rnl_…
Content-Type: application/json

{
  "from": "[email protected]",
  "to": "[email protected]",
  "subject": "Your receipt",
  "html": "<p>Thanks for your order.</p>"
}

Production checklist

  • Domain added and verified in Ranla
  • from uses verified domain
  • API key only in secrets, not in frontend
  • Bounce/complaint handling via webhooks if needed