Build and validate an API
Turn an inspected collection into a saved API contract, then check that its records fit your application. A useful validation result connects the selected source, reviewed fields, accepted definition, and a bounded execution.
On this page
Before you begin, choose a collection URL and identify the fields your application requires. Use a website you are authorized to access. Source availability and supported collection behavior depend on the inspected website.
Inspect the collection#
Open Create API in your workspace and enter the source URL. Add a short description when the page contains several possible collections. For example: “Product name, price, currency, and product URL from this category.”
Review the collection found by inspection. A matching domain alone does not establish that the selected collection contains the records you want. Check the actual sample records against the visible website: navigation items, advertisements, and login or challenge pages must not become records.
If inspection is interrupted, use the saved draft to check its outcome before starting another inspection. An interrupted connection can leave work in progress.
Review fields before building#
Select the collection and retain the fields your application will use. Compare several examples when available, including records with missing or unusual values. Use fields and schemas to check types, optional values, and any fields that depend on detail-page collection.
Record your acceptance criteria before running the build:
| Check | Example acceptance criterion |
|---|---|
| Record identity | A stable source identifier or reviewed record URL is present |
| Required fields | Every usable record has a product name and URL |
| Value meaning | Price is numeric and currency is known when price is used |
| Scope | Records belong to the selected category |
| Collection limits | The validated plan supports the intended page and detail limits |
These criteria belong to your integration. The example does not define a universal product schema.
Check the accepted build#
Create the API after reviewing the selection. Keep the saved build reference while the job runs. A queued or running build is not an accepted API; a failed build needs its reported recovery action.
After validation, inspect the saved schema, examples, source identifier, definition version, limits, and request example. The console verifies the accepted build with at most one collection page and no detail requests. That check demonstrates behavior within this small scope; it does not establish full-catalog coverage or ongoing source health.
If verification returns partial output, inspect its summary and keep the accepted build available for diagnosis. Do not treat a populated preview or successful HTTP response as complete verification.
Validate your application path#
Follow the quickstart to run a bounded request using the saved connection details and version. Test the parser, required-field checks, duplicate handling, and storage path your application will actually use.
Retain the response with its summary and requested limits. Confirm the returned version matches the contract you reviewed. Expand collection limits only after reading pagination and output; repeated runs do not automatically advance to the next page.
Use the production checklist before enabling recurring work. Continue checking source changes and monitoring after the first successful run.