# Choosing a source

Begin with one collection you can describe in a sentence. A website homepage may contain several kinds of records; a category or results URL gives inspection a clearer boundary.

## A collection to inspect

Suppose you want table lamps for a product comparison. Start with the fictional collection URL `https://example.com/lighting/table-lamps/` and this scope: “Product name, price, currency, availability, and product URL for table lamps in this category.” The domain and records in this guide are illustrative; they are not a supported source or a live CleanedWeb result.

The collection URL identifies where to look. The sentence identifies what one record is and which fields matter. Keep filters such as location, category, or date explicit rather than assuming the builder will infer them from a homepage.

## Review the inspection

Check that the inspected page is the intended collection, that the suggested data type describes products, and that observed examples represent individual lamps rather than navigation links or advertisements. Confirm that the requested fields appear in the inspected evidence. A field seen on one detail page may not be available across the collection.

If inspection finds a different collection, try a more specific public URL or narrow the scope. If the source requires a login, blocks access, or does not expose enough evidence, stop and ask for scoping help. Do not treat a page loading, a suggested type, or a nonempty preview as proof that an API can be built.

## Decide what moves forward

Continue only with the collection and fields you have reviewed. Selecting a type does not map every field, extract a complete dataset, or activate an API. The next step is to review [fields and schemas](/docs/schemas/) and validate a build before connecting an application.