Define one HTTP request/response contract in an API file, mount it in a Component, supply typed request values, and verify the loading, success, and failure states without exposing production credentials.
Coverage: UI + MCP. Runtime success also depends on the endpoint, browser/network policy, authentication, and the exported application's environment.
Collect a safe test contract:
method: GET, POST, PUT, or DELETE;
host and path;
whether cross-origin cookies must be sent;
string headers;
string, number, or boolean query fields;
typed request-body fields;
one object or list response shape;
representative non-sensitive test values.
Use a development endpoint or fixture. Do not put a private token, password, or production secret into documentation, a screenshot, a prompt, or client-exported configuration.
Create or open an API file below APIs.
Choose the method and credentials mode.
Set the host and path configuration.
Add only the required Headers, Query, and Body fields with accurate types.
Define the Response fields and choose Object or List.
Add test cases that cover at least a normal request and one edge/error input.
Review the generated Config, Headers, Query, Body, and Response contract.
Header declarations are strings. Query fields support string, number, and boolean. The response kind determines whether the declared response shape is returned once or as an array.
Open the consuming Component and switch to Logic.
Mount the API data source so its request and state paths become available.
Supply configuration, headers, query, and body values from constants or Component properties/states.
Bind loading, error, and response values to visible elements.
Connect the request to a deliberate trigger; do not fire a write endpoint merely by opening an editor preview.
Preview the loading, success, empty, and failure states.
In the
Websiteproject, inspect<API file reference>and<consumer Component reference>. Define or update only this contract:<method, host/path, credentials, request fields, response shape>. Use non-sensitive test values. Mount the API in the Component, supply<value sources>, and bind loading, error, and response to<target elements>. Do not send a request that mutates external data. Read both files back, verify the safe Preview paths, inspect generated output, list runtime/CORS/auth assumptions, and stop.
The API tool family reads and updates method, credentials, response kind, fields, and test cases. Component logic uses data-source mounting and request configuration operations. The agent should read current field IDs and types before wiring values.
Check four layers:
Contract: request/response names and types match the endpoint.
Component: mounted references and bindings resolve without diagnostics.
Preview: loading, success, empty, and error states render intentionally.
Consumer: generated modules build in the intended application and the deployed origin satisfies URL, CORS, cookie, and authentication requirements.
A successful schema edit does not prove network access. A successful test request does not prove that production credentials belong in the frontend.
API definitions and Component mounts are persisted file changes with their respective histories. Undo and verify each file separately.
An actual POST, PUT, or DELETE request can change an external system. Component-file undo cannot reverse that effect. Require explicit authorization and a destination-specific recovery plan before running it.
Config begins with host/path strings; deployment must provide usable values.
Cross-origin cookies require compatible endpoint and browser policies.
Mounted values must match the declared field types.
Removing or changing a field can break Component mounts and generated consumers.
Client-side output must not contain secrets that require server protection.