Discover and query data
Find a visible service, inspect its published contract, and run a working example. The workbench performs those steps on the live API without leaving this page. Its token is shared with the full API reference for this tab session.
Live API workbench
Connect, choose a service, inspect its contract, and run a query.
- Type
- Delivery
- Access
Query result
Raw JSON response
Enter a token to begin.
List visible services
GET https://quicklookup.com/api/v1/catalog/services?q=weather
Authorization: Bearer <your API key>
Use human text for broad search. Add exact, repeatable type, classification, or tag
filters when you already know the catalogue values. Results are filtered by the caller's
grants and each service's access policy. An inaccessible service is not disclosed.
Choosing Time-series families lists each measurement once. The workbench selects the best available concrete variant and exposes the authorized source, resolution and quality alternatives before running a query.
Inspect the contract
Follow the result's detailUrl. It returns labelled inputs, valid input methods, selectable
outputs, units, source health, limits, and runnable examples. Build query controls from this
response instead of assuming a service-specific schema.
See and run the statement
Every service query page shows, under PostgreSQL statement, the statement that fetches
the data for the inputs in the form: the page over the CTX foreign tables for stored data
(with %(name)s placeholders and the bound values listed), and for on-demand services also
the statement CTX runs against the source relation for the same window. Run statement
executes it exactly as shown — the text is derived by the same code the service runs and is
never editable; only the form inputs are, and they are bound as parameters. The result is
the raw rows PostgreSQL returned, next to the service's shaped result. Use it to see why a
page is what it is, or to check what a source answers before the service stores it.
Filter in the console
The console's Filters panel builds the where, search and anyOf of a query without
writing JSON. Its field list is the feed's own contract, grouped by the kind of question:
What it is (a value chosen from what the feed holds, each with the number of rows carrying
it), How much (a number: exactly, at least, more than, at most, less than), When (a date
or a time: on, before, after) and Exact text (typed, or contains). A flag is Yes / No.
The values on offer are read from the feed's stored rows: its properties, its numbers, and
its own fields (sub-type, country, regions, tags, venue) alike, each with the number of rows
carrying it, up to a hundred values. A number or a date always says the stretch the feed
covers — -95,000 – 525,000 · 333 values — even when there are too many to list. A field
with more values than that is searched as you type: its picker loads the feed's whole list
once, most-used first with counts, keeps it for the session, and filters it in the browser
as you type — nothing is asked per keystroke. Only a field with nothing stored is typed
into. An on-demand feed
that nobody has run yet holds none, so opening its console for the first time reads its
example window once; the rows stay stored and every later visit starts from them.
Filters in one set must all match (AND). + OR alternative adds a second set, and a row
is kept when any set matches (OR) — the two joiners in the panel say which is which.
Everything the panel holds is written into the page's address as plain parameters
(filter.rating__gte=4, filter.genre=News,Sport, or1.filter.genre=Film), so a query can
be shared as a link, saved as context, or edited by hand.
Run a query
Send the example body to queryUrl. Event-feed examples can also include the advertised
where, search, and spatial.near capabilities. A nearby event query matches an
occurrence when any of its sites is within the radius: the response carries sites,
distanceMeters to the nearest site and matchedSite, the 1-based index of the site that
matched, while venue and location keep reporting the first site. seriesGids narrows
to given series and collapse: "series" returns one occurrence per series.
{
"inputs": {},
"select": ["timestamp", "value"],
"order": "asc",
"limit": 100
}
Return nextCursor unchanged to fetch the next page. limit is the response page size;
the date range controls the complete temporal result. On-demand services politely fetch that
range in source-supported chunks and retain it in ClickHouse before serving continuations.
See Query contracts, paging, and errors before implementing a client.