How to Integrate Lovable with Notion

Go to notion.so/my-integrations and click 'New integration'. Give your integration a name (e.g., 'Lovable App') and select the workspace it should have access to. Under capabilities, select what your integration needs — 'Read content' is required for displaying data, and 'Update content' and 'Insert content' are needed for write operations. For a read-only knowledge base, read content is sufficient. Click 'Submit' to create the integration, and on the next page copy the Internal Integration Secret — this is your API token. It starts with 'ntn_' or 'secret_' depending on the Notion API version. Now the critical step that many developers miss: Notion integrations do not automatically have access to any workspace content. You must explicitly share each page or database you want to access with your integration. Open Notion, navigate to the page or database you want to connect, click the three-dot menu in the top right (or the 'Share' button), and in the 'Connections' section select your integration by name. For databases, sharing the parent page that contains the database shares all databases inside it. If you share a top-level workspace page with your integration, all child pages become accessible, which simplifies setup for large workspaces. Any page not shared with the integration will return a 404 error when queried via the API — a common source of confusion for developers new to Notion's permission model.

In your Lovable project, open the Cloud tab by clicking '+' next to the Preview panel, then navigate to the Secrets section. Click 'Add Secret' and create a new secret named NOTION_TOKEN with your Notion integration secret value. This is the only credential Notion requires for its internal integration authentication pattern. The token grants access to all pages and databases explicitly shared with your integration — it does not provide access to your entire Notion workspace, only the content you have chosen to share. This selective permission model makes it safer than a full workspace API key, as you control exactly what is accessible. You may also want to add NOTION_DATABASE_ID as a second secret containing the ID of your primary Notion database. Database IDs are the UUID visible in the Notion page URL — for a database at notion.so/workspace/some-title-abc123def456, the ID is 'abc123def456' (or with hyphens as a standard UUID format). Storing the database ID as a secret rather than in your code makes it easy to swap databases without redeploying. Lovable's SOC 2 Type II certified Cloud Secrets storage ensures these tokens are encrypted at rest and never accessible from client-side code or browser network requests.

Ask Lovable to create a Supabase Edge Function called notion-api that proxies requests to the Notion API. The function reads the integration token from Deno.env.get('NOTION_TOKEN'), accepts a path (like 'databases/{id}/query' or 'pages/{id}'), HTTP method, and optional request body, constructs the full Notion API URL as https://api.notion.com/v1/{path}, adds the Authorization: Bearer header, the required Notion-Version header (set to '2022-06-28' for the current stable API version), and a Content-Type: application/json header. It forwards the request and returns the Notion API response. Key endpoints to support include POST /databases/{id}/query for database queries with filters and sorts, GET /pages/{id} for page metadata and properties, GET /blocks/{id}/children for page block content, POST /pages for creating new database records, and PATCH /pages/{id} for updating page properties. The Notion API response structure varies by endpoint — database queries return a results array of page objects, block children return a results array of block objects with type-specific content. Build the Edge Function to handle any path generically rather than hardcoding specific endpoints, keeping it flexible for all Notion API operations.

1import { serve } from "https://deno.land/std@0.168.0/http/server.ts";
2
3const corsHeaders = {
4  "Access-Control-Allow-Origin": "*",
5  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
6};
7
8serve(async (req) => {
9  if (req.method === "OPTIONS") return new Response("ok", { headers: corsHeaders });
10
11  try {
12    const notionToken = Deno.env.get("NOTION_TOKEN");
13    if (!notionToken) throw new Error("NOTION_TOKEN not configured");
14
15    const { path, method = "GET", body: reqBody } = await req.json();
16    if (!path) throw new Error("path is required");
17
18    const url = `https://api.notion.com/v1/${path}`;
19
20    const fetchOptions: RequestInit = {
21      method,
22      headers: {
23        "Authorization": `Bearer ${notionToken}`,
24        "Notion-Version": "2022-06-28",
25        "Content-Type": "application/json",
26      },
27    };
28
29    if (reqBody && method !== "GET") {
30      fetchOptions.body = JSON.stringify(reqBody);
31    }
32
33    const response = await fetch(url, fetchOptions);
34    const data = await response.json();
35
36    if (!response.ok) {
37      const errorMsg = data.message || data.code || JSON.stringify(data);
38      throw new Error(`Notion API error (${response.status}): ${errorMsg}`);
39    }
40
41    return new Response(JSON.stringify(data), {
42      headers: { ...corsHeaders, "Content-Type": "application/json" },
43    });
44  } catch (error) {
45    return new Response(
46      JSON.stringify({ error: error.message }),
47      { status: 500, headers: { ...corsHeaders, "Content-Type": "application/json" } }
48    );
49  }
50});

With the Edge Function working, ask Lovable to build the data fetching and display layer. The Notion database query endpoint accepts a filter object and sorts array in the request body. Filters follow a specific structure: each filter has a property name, a condition type (equals, contains, is_empty, etc.) matching the property type, and a value. For example, filtering a select property named 'Status' to equal 'Published' looks like: { filter: { property: 'Status', select: { equals: 'Published' } } }. Sorts specify a property and direction: { sorts: [{ property: 'Created time', direction: 'descending' }] }. The database query response returns page objects where each page has an id (UUID), properties object with the database schema values, and url. To display the full content of a page, make a second call to GET /blocks/{pageId}/children to retrieve the block tree. Each block has a type (paragraph, heading_1, heading_2, bulleted_list_item, code, image, etc.) and a type-specific content object. Build a simple block renderer in React that maps block types to appropriate HTML elements — paragraphs become p tags, heading_1 becomes h1, etc. This is the minimum needed to display Notion page content in your Lovable app. For complex formatting or deeply nested blocks, consider using an existing Notion renderer library.

Extend your integration with write capability to create new database records and update existing page properties from your Lovable app. Creating a new Notion database page requires a POST to /pages with a parent object specifying the database ID and a properties object matching the database schema exactly. Each property value must be formatted according to its type — a title property needs { title: [{ text: { content: 'Your title' } }] }, a select property needs { select: { name: 'Option Name' } }, and a date property needs { date: { start: '2026-03-30' } }. Updating a page uses PATCH to /pages/{pageId} with only the properties you want to change — you do not need to include unchanged properties. Ask Lovable to generate a form component that matches your database schema. Describe each property's name and type in your prompt so Lovable can generate the correct input types (dropdowns for select, date pickers for date properties, etc.) and format the API request body correctly. After a successful create or update, invalidate the cached database query results and refetch to show the latest data. Add optimistic UI updates where appropriate to make the form submission feel instantaneous even if the Notion API call takes a moment.