---
title: "How to Use Unified with Lovable"
img: https://s3.us-east-2.amazonaws.com/unified-article-images/how_to_use_unified_with_lovable-icon.png
date: 2025-12-19T00:00:00.000Z
tag: Product
description: "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..."
url: "https://unified.to/blog/how_to_use_unified_with_lovable"
---

# 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


```javascript
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](/embeddedauth), 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**

    ```bash
    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](/technology) 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.


### Option B: Redirect to a Unified-hosted authorization URL (recommended default)


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:

- A [Unified.to](http://unified.to/) [workspace ](https://app.unified.to/apikeys)[API](https://app.unified.to/apikeys) key in the `Authorization` header
- A `connectionId` to scope the request

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)


```javascript
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](/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**](https://app.unified.to/login)


[**Book a demo**](https://calendly.com/d/cph9-g8n-jzg/connect-with-unified)