Skip to content
Working with Waveform

Landing page API or MCP: choose the interface for your workflow

Compare scripted page automation with an assistant using MCP. Plan permissions, retries, review and publication before connecting Waveform.

Choose based on who controls the work

Use an HTTP API when your application controls a repeatable sequence of requests. Use MCP when an assistant needs to discover and call supported tools while helping a person complete a task. Both interfaces let you create and manage pages with workspace permissions.

In Waveform, the public API and MCP use the same supported operation layer. The difference is how your caller interacts with it. The API suits a service that already has a job queue and explicit steps. MCP suits a connected assistant that selects tools from the available contract. The quickstart covers client setup and authentication.

Source: Waveform: Agent quickstart

Start with one complete customer task

Suppose an agency wants to prepare a landing page from an approved campaign brief. A useful first integration accepts the brief, starts one generation, records the returned identifier, reads progress, and presents the result for review. Publishing is a separate decision. That is easier to inspect than a broad instruction to automate the agency’s websites.

Write down what success means before choosing the interface: the draft is available, its files can be inspected, and the reviewer knows which version they are looking at. Then name the failure cases: insufficient credits, an interrupted connection, a request still in progress, or a result requiring attention. These cases belong in the workflow design, not just a generic retry handler.

Arcjet website design concept: Request traces, errors and deployment changes in one timeline.
Arcjet software website design, made with Waveform. Explore the full concept

Give the integration the permissions its task needs

Begin with a read-only identity request so you can confirm the workspace and available authority. Keep credentials in the integration’s private configuration. Do not put them in page source, screenshots, a public repository or a browser field intended for ordinary content.

For a draft-building workflow, distinguish permission to create or edit from permission to publish. Confirm the account and credit setup before deliberately starting paid work. If a workflow needs only to monitor an existing job, do not grant or request unrelated mutation capabilities.

Source: Waveform: Agent quickstart

Check an interrupted request before retrying

An interrupted connection does not prove that a request failed before acceptance. Persist the exact request and its idempotency key before sending it. If the connection is interrupted, keep those values and inspect the existing request or returned generation. Changing the key can turn a recovery attempt into new work.

Waveform’s automation examples describe saved requests, request lookup and bounded monitoring. Use those patterns rather than a loop that repeats a creation request whenever a response takes too long. A returned identifier is something to continue observing. Monitoring should stop or surface a clear waiting state when it reaches its limit.

Source: Waveform: Automation examples

Treat the result, download and publication as different steps

A design preview helps someone choose a direction. A working page and its source allow a different kind of review. A downloadable artifact identifies the exported files. A public release makes a selected version available at a serving address. Keep those distinctions visible in the integration so a person can tell what has actually happened.

For complete sites, publish a coherent selected release rather than whichever pages happened to finish first. Check forms, links and the intended domain after publication. A downloaded page may still depend on a configured form endpoint or another external service. The publishing guide describes the supported operations and required authority; use it as the current contract.

Source: Waveform: Agent publishing guide

Choose the smallest integration that solves the task

Choose the API if the next action can be determined by your own application state and you need a clear request/response contract. Choose MCP if the work benefits from a person discussing options with an assistant that can discover the relevant tools. You can use both in one organization, provided the ownership and review steps remain understandable.

Before expanding to bulk work, exercise a single task with explicit spending and publishing intent. Save the request, observe completion, inspect the result, verify the artifact and test recovery from an interrupted read. Use the same checks when adding another client or workflow.

Sources and further reading