# Landing Pages API > The landing pages API lets integrations manage hosted capture pages outside the app. This guide explains when to list, create, update, or delete landing pages, how page definitions depend on tags and fields, and how to update public pages safely. - Human page: https://mailrith.com/developers/landing-pages - Markdown page: https://mailrith.com/developers/landing-pages.md - Category: API Resources - Reading time: 6 min read - Last updated: 2026-06-13 - Related keywords: Landing Pages API, Landing Pages API developer docs, API Resources, API Resources developer docs, Mailrith developer docs, Mailrith public API, Manage Landing Pages, Endpoint Overview, Change Landing Pages Safely, Forms API, Custom Fields API, Webhook Subscriptions API ## AI Agent Notes - Use this page as implementation guidance, then validate exact endpoint fields against the OpenAPI document. - Keep API keys server-side and workspace-scoped unless a guide explicitly says otherwise. - Do not invent privacy, consent, or lawful-basis evidence. Send only fields that appear in the OpenAPI schema for the endpoint you are using. ## What this guide covers Manage Mailrith-hosted landing pages, page definitions, settings, and public URLs. ## Manage Landing Pages Landing pages are Mailrith-hosted subscriber capture pages. They can include page content, generated token-based public URLs, optional Pro custom-subdomain homepages and slugs, SEO settings, analytics settings, and form-backed subscriber capture. Use the public landing pages API when an external builder, migration script, agency tool, or internal workflow needs to manage hosted pages without requiring a user to click through the app. Landing pages often depend on tags, custom fields, and form-style capture settings. Review those dependencies before you create or update pages programmatically. 1. List existing landing pages before you create replacements during migration work. 2. Confirm that the required tags and custom fields already exist in the workspace. 3. Create or update the landing page using the public schema from [API Reference](https://mailrith.com/developers/api-reference.md). 4. Store the saved landing page ID and public URL in the external system. 5. Ask a Mailrith user to test the public page and subscriber submission path before you send traffic to the page. The test succeeds when the page loads, accepts a test subscriber, and applies the expected fields, tags, and consent choices. 6. Do not delete an old landing page until old links, ads, and embeds have been retired. - List landing pages when an integration needs an inventory of hosted capture pages. - Create landing pages when another system owns page setup and needs to keep Mailrith in sync. - Update landing pages when external copy, layout, SEO, analytics, or capture settings change. - Delete landing pages only after the public page has intentionally been retired. ## Endpoint Overview `GET /v1/landing-pages` returns landing pages in the authenticated workspace. Item endpoints let you inspect, update, or delete one page. `POST /v1/landing-pages` creates a landing page with a generated public URL and page definition. Pro workspaces can also set `customPath`, shown as Custom Slug in the app, but only after the workspace has a verified landing page subdomain. Workspace settings control which landing page opens directly at the subdomain homepage. When a visitor subscribes through a landing page form, Mailrith can send a `landing_page.submitted` webhook event to integrations such as Zapier. Landing page access uses `landing_pages:read` and `landing_pages:write` scopes, which are separate from the forms scopes. Related OpenAPI operation groups: - Landing Pages **List Landing Pages** ```bash curl "https://api.mailrith.com/v1/landing-pages?limit=25" \ -H "Authorization: Bearer mrk_example_secret_key" ``` ## Change Landing Pages Safely Landing pages are public pages. A programmatic update can immediately affect ad traffic, SEO previews, analytics, and subscriber capture. Before you delete or replace a landing page, confirm where the URL is linked, which tags the page applies, which custom fields the page collects, and what fallback plan you will use if old traffic still arrives. - Update a landing page in place when public URLs must keep working. - Create a new landing page when the new page has a different campaign, audience, or attribution purpose. - Keep page names descriptive so users can identify each page in the Mailrith app. On Pro workspaces, keep custom slugs stable after a page is shared. - After you change a landing page, open the public URL and submit a test subscriber through the real page. ## Related Guides - [Forms API](https://mailrith.com/developers/forms.md): The forms API lets integrations manage capture forms outside the app. This guide explains when to list, create, update, or delete forms, how forms depend on fields and tags, and how to update live forms without breaking website signups. - [Custom Fields API](https://mailrith.com/developers/custom-fields.md): Custom fields define the typed workspace schema shared by subscribers, forms, and segments. This guide explains how to choose field types, map external data sources, create field definitions, and avoid schema changes that break forms or reports. - [Webhook Subscriptions API](https://mailrith.com/developers/webhook-subscriptions.md): Webhook subscriptions let external systems receive Mailrith events for syncs, dashboards, fulfillment, and audit trails. This guide explains when to use webhooks, how to manage subscriptions, why you must store the signing secret immediately, and how receivers should verify and deduplicate deliveries.