Landingi
Web PlatformConnect AI agents to Landingi, a landing page builder with a programmatic page generation API. Agents start programmatic processes, list and inspect runs, and retrieve the generated landing pages so hundreds of personalized page variants ship without manual page building.
What This Integration Enables
Landingi's public API is one thing, and being honest about that is the fastest way to understand what this connector is for. Leads, campaigns, domains, and ordinary landing page editing are not exposed by the vendor and are therefore not here. What is exposed is Programmatic Landing Pages: a batch machine that takes one source page and a list of variants, substitutes per-variant placeholder values, and produces many pages from a single call. So this is not a page-builder connector. It is a job runner whose output happens to be live URLs, and it suits teams whose landing page problem is combinatorial rather than creative, meaning the design is settled and what is left is four hundred versions of it.
The four actions map cleanly onto that job. Start Programmatic Process launches a run and returns a process identifier immediately, because generation is asynchronous. Get Programmatic Process polls that identifier and reports status, progress counters, and the credits the run cost. List Programmatic Processes gives the history across the account, searchable by name and filterable by source landing page, which is how a flow answers the question of whether this matrix has already been generated. List Process Landing Pages goes one level deeper and returns the individual pages a run produced, each with its name, its assigned URL, its publication and archive state, its status, and any error that occurred on that specific row. That last action is what makes a run auditable rather than merely finished, because a process can report success overall while three of its pages failed.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A location page for every store, generated from the store list
The authoritative list of locations lives in Google Sheets, where operations keeps opening hours, addresses, and the local manager. On a schedule the agent reads the sheet, builds one variant row per location with the placeholder values the source page expects, and checks each row for completeness. A location with no phone number does not become a page with a blank phone line; it becomes an automation exception named for the store, held out of the run, and reported. Everything complete goes into a single Start Programmatic Process call. When a store's hours change next quarter, the same flow regenerates only the affected rows rather than reissuing the whole set.
Partner pages that follow the partner record
A new reseller is approved in HubSpot. The agent reads the partner's name, logo URL, territory, and contact, assembles a single-row variant, and generates the co-branded page for them. Because Get Programmatic Process reports the credits cost of each run, the flow can log what each partner activation actually consumed against the campaign budget rather than discovering the total at the end of the month. The finished URL goes back onto the partner record in HubSpot and into the welcome message, so the page and the record never drift apart.
The audit run that reads the errors nobody opens
A large generation run finished last night and reported success. The agent calls List Process Landing Pages for that process and reads every row, not the summary: which pages have an assigned URL, which are published, which are archived, and which carry an error. It groups the failures by their message, cross-references the source rows that produced them, and posts a short report to Slack naming the seven variants that did not produce a usable page and the reason each one failed. Nobody has to open the Landingi dashboard to find out that a run was not as clean as its status suggested.
Human-in-Loop Highlight
The gate on this connector is justified by an action that does not exist. Landingi's public API gives you four calls, and none of them removes a generated page. Start Programmatic Process can create hundreds of pages at hundreds of URLs, and the only thing the API will do afterward is tell you about them. Removing them means a person in the Landingi dashboard doing it by hand, once per page, after the search engines have already had a look. That asymmetry, an unlimited create with no matching delete, is the reason the manifest and not the output is where a person belongs.
So the agent builds the run and stops in front of it. It posts the manifest to the campaign owner with the numbers that make the decision real: "Programmatic run ready against source page Q3 Local Offer. 412 variants assembled, 6 held back for missing placeholder values and listed below. Three sample rows rendered as they will appear: Austin, Fort Worth, and Tulsa. Domain URLs checked against the 118 pages already generated from this source page, no collisions. Launching this run generates 412 pages and consumes credits, and nothing in the API can delete them afterward. Start it?" That is human-in-the-loop placed where the cost is actually incurred, rather than as a rubber stamp after the fact.
The second gate is the publication flag, and it is the reason the workflow above ends with a person rather than an agent. Start Programmatic Process accepts an immediate publication setting, and an agent should leave it off as a matter of policy. Generating unpublished means the pages exist, their assigned URLs are known, and List Process Landing Pages will report exactly which rows errored, all while nobody outside the team can reach a single one of them. The campaign owner then publishes in Landingi, having actually looked. Two hundred pages generated and reviewed is a good afternoon; two hundred pages published with a broken placeholder is a week of cleanup that the API cannot help with.
Agent Capabilities
4 actionsProgrammatic Page Generation
2- Start Programmatic Process Starts a run that generates many landing pages from one source page in your Landingi account, with each variant supplying its own name, optional domain URL, and placeholder values. The run is asynchronous and returns a process identifier to poll. It also accepts an immediate publication setting, and leaving that off is what separates a reviewable batch from a live one.
- List Process Landing Pages Returns the individual landing pages a run produced, each with its name, assigned URL, publication and archive state, status, and any error recorded against it. Supports searching by name or assigned URL and filtering by status. This is the row-level truth a run's summary status does not give you, and the action that makes a large generation auditable.
Process Monitoring
2- Get Programmatic Process Returns the details of a single run, including its status, progress counters, credits cost, and source landing page. The poll a flow uses to wait for an asynchronous run to finish, and the action that reports what the run actually cost in credits.
- List Programmatic Processes Retrieves the runs created in the account with their status, progress counters, and source page. Supports searching by process name, filtering by source landing page UUID, and sorting by creation date or name. Used to check whether a matrix has already been generated before generating it again, and to build a history of what shipped when.
Frequently Asked Questions
What can FlowRunner do with Landingi?
FlowRunner agents can run Start Programmatic Process, List Programmatic Processes, and Get Programmatic Process in Landingi, plus 1 more action.
Does connecting Landingi to FlowRunner require OAuth?
No. Landingi connects to FlowRunner with an API key, no OAuth flow required.
Can Landingi trigger a FlowRunner workflow automatically?
Landingi doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Landingi
$100 in credits. No card required. Connect in minutes.