Unified.to
All articles

How to Use Unified with Lovable

December 19, 2025

Lovable makes it easy to design and ship application logic quickly. Unified.to makes it easy to add and maintain SaaS integrations. Used together, they let you build Lovable apps that can read and act on real customer data across CRMs, calendars, file storage, and more — without embedding credentials or SDKs directly in Lovable.

This guide explains the supported way to use Unified.to with Lovable: through a backend integration layer.

Why a backend layer is required

Lovable applications do not provide a general-purpose backend runtime and should not store secrets or API keys client-side. Unified.to APIs, by design, must be called from a secure backend using an API key and a customer-specific connectionId.

Because of this, Unified.to is not embedded directly inside a Lovable app. Instead, Lovable triggers backend actions, and the backend calls Unified.to.

This architecture keeps credentials secure and aligns with how both platforms are designed to be used.

High-level architecture

Lovable UI / Agent
↓
Backend action (serverless or API)
↓

Unified.to
 API
↓
Customer's SaaS tools (CRM, calendar, storage, etc.)

Lovable handles UX and orchestration. Unified.to handles integrations and authorization. Your backend is the security boundary between them.

Step 1: Set up Unified.to

Create a Unified.to workspace and generate an API key.

In Unified, enable the integration categories you plan to support (for example: CRM, Calendar, File Storage). Unified manages OAuth, API keys, token refresh, and provider-specific edge cases for you.

Step 2: Handle end-user authorization

Before your Lovable app can access a customer's SaaS data, that customer must authorize their account with Unified.to. Unified supports both OAuth-based and API-key–based integrations. In all cases, authorization results in a connectionId that your backend uses for API calls.

There are two supported authorization patterns when working with Lovable.

Option A: Embed Unified Auth in the exported Lovable React app

Unified provides a pre-built authorization directory component for React that handles OAuth- and API-key–based integrations.

This option assumes you export the Lovable project (GitHub/download) and run it as a standard React app where you can install npm packages and control OAuth redirects. Lovable's hosted runtime does not guarantee support for third-party auth components.

Implementation (exported Lovable React app)

  1. Export your Lovable project
    Download the source or connect it to GitHub so you can run it as a normal React app.
  2. Install the Unified React authorization package
    npm install @unified-api/react-directory
  3. Add a Connections or Integrations route
    Create a page such as /connections or /settings/integrations and render Unified's authorization directory component using the code snippet provided in the Unified dashboard:
    • Go to app.unified.to → Embedded components
    • Select the Authorization Directory
    • Configure scopes and redirect URLs
    • Copy the React snippet from the Embedded Code tab
    • Paste it into your exported Lovable React app

    Do not improvise component props — use the snippet generated by Unified, as it reflects your workspace configuration and scopes.

  4. Handle the authorization redirect
    On successful authorization (whether via OAuth or API token), Unified redirects the user to your success_redirect URL with the following query parameters:
    • id — the newly created connectionId
    • state — your original state value
    • nonce — a random nonce
    • type — integration type
    • sig — HMAC signature to verify integrity

    Your app should:
    • Read the id value from the URL
    • POST it to your backend
    • Associate it with the logged-in user
  5. Verify the signature (recommended)
    Use the sig value to verify the redirect payload using your workspace secret, as documented by Unified.

Even when using the embedded React component, all Unified API calls and credential handling must remain in your backend. Lovable should never store API keys or call Unified directly.

If you are using Lovable's hosted runtime without exporting the project, treat this approach as best-effort only. The most reliable option in that case is Option B.

You can also initiate authorization by redirecting users to a Unified-hosted authorization page.

In this model:

  • Lovable renders a simple 'Connect account' action
  • The user is redirected to a Unified-hosted authorization URL
  • Unified completes OAuth or API-key validation
  • Unified redirects back to your application with a connectionId
  • Your backend stores the connectionId and uses it for all future API calls

This approach avoids assumptions about embedded components and is the most robust option when working with Lovable.

What your backend receives

Regardless of the authorization method:

  • Unified returns a connectionId representing the authorized account
  • Your backend stores this ID and associates it with the user
  • All subsequent Unified API calls use:
    • Your workspace API key
    • The user's connectionId

The connectionId is the only identifier required to access that user's connected SaaS account going forward.

Step 3: Create a backend endpoint that calls Unified.to

Unified.to APIs are called using:

You can use any backend runtime (Vercel, Cloudflare Workers, AWS Lambda, etc.). SDKs are optional — raw REST works just as well.

Example: list CRM contacts (read-only)

export async function listContacts(connectionId: string) {
  const res = await fetch(
    `https://api.unified.to/crm/${connectionId}/contact?limit=25`,
    {
      headers: {
        Authorization: `Bearer ${process.env.UNIFIED_API_KEY}`,
        "Content-Type": "application/json",
      },
    }
  );

  if (!res.ok) {
    throw new Error("Unified API request failed");
  }

  return res.json();
}

Unified returns normalized objects across providers (Salesforce, HubSpot, Zoho, etc.), so your Lovable app doesn't need vendor-specific logic.

Step 4: Make the backend action available to Lovable

Lovable can trigger backend actions via:

  • HTTP requests
  • Agent actions
  • Tool-style function calls

From Lovable's perspective, this is a callable data source. It doesn't know (or need to know) that Unified is behind it.

Lovable sends:

  • The user identifier
  • The action to perform (e.g. 'fetch contacts')

Your backend:

  • Looks up the user's connectionId
  • Calls Unified.to
  • Returns structured data to Lovable

Step 5: Use the data inside Lovable

Once data is returned, Lovable can:

  • Display it in the UI
  • Use it in conditional logic
  • Feed it into AI workflows or automations

Because Unified returns real-time data and never caches customer records, Lovable always works with live information from the source system.

A note on MCP (Model Context Protocol)

Unified.to also provides an MCP server that makes integration actions available as tools for LLMs.

In the context of Lovable:

  • MCP can be useful during agent-assisted app creation
  • MCP does not replace Unified's REST API and is not designed for runtime application access to end-customer data.
  • MCP does not run inside the deployed Lovable app

For runtime application logic, you should always call Unified through your backend.

Summary

Using Unified.to with Lovable requires a simple but important architectural decision:

  • Lovable handles UI, logic, and orchestration
  • Unified.to handles integrations, auth, and normalization
  • Your backend connects them securely

This approach avoids client-side secrets, scales cleanly, and lets you add dozens of SaaS integrations without maintaining custom connectors.

Start your 30-day free trial

Book a demo

All articles