Skip to main content
POST
Fetch

When to use this

Use /v1/fetch when:
  • The caller knows exactly which fields they need.
  • The workflow is deterministic and you don’t want LLM latency or variability on every call.
  • You are powering a downstream model that needs raw structured values rather than synthesized prose.
  • You want a preset bundle (e.g., everything needed for flood underwriting) in one round trip.
Use /v1/ask instead when the question is phrased in natural language and the right answer requires combining values with interpretation.

Request shape

The body accepts lat, lng, and at least one of fields or preset (both is allowed — preset expands first, then fields unions in, and the combined list is capped at 50).

Presets

Presets are use-case bundles. Pass "preset": "flood_risk" and you get the floodplain-relevant fields without naming each one. The preset expansions:
To add fields beyond a preset’s bundle, send both:

Example 1: flat fields list in Manhattan

Example 2: preset on a coastal coordinate

Houston, downtown — flood-relevant features in the same call:

Per-field response shape

Each value in fields is a self-contained record: A failed entry additionally carries error (string) and retryable (bool); its value is null. Read status to tell a real value from no-data from a failure without parsing notes.

The honesty pattern: status + partial_failures

/v1/fetch always returns 200 unless the request itself is malformed. A field that failed to fetch is surfaced two ways, so it can never be silently dropped or misread as “not requested”:
  1. In fields, with "status": "failed", "value": null, and the error + retryable hints inline — so every requested field is present in fields, distinguished by its status.
  2. In partial_failures, a flat list of just the failures (kept for back-compat).
Two recoverability hints (present on both the fields entry and the partial_failures record):
  • retryable: true — transient and worth a retry with backoff: a timeout / connection reset, or a metered quota that resets later (e.g. a Regrid billing-period exhaustion).
  • retryable: false — retrying won’t help: the upstream returned a structured error (a missing plan entitlement, an unsupported request).
We never silently drop a field we couldn’t fetch: every requested field appears in fields with a status (ok / absent / failed). Read status (or cross-check partial_failures) rather than assuming presence in fields means success — a failed field is present too.

Limits

  • 50 fields maximum per request (after preset expansion). Exceeding this returns 400 fields_too_many.
  • No batching in V1. One coordinate per request. Loop client-side for N coordinates.
  • No caching headers on /v1/fetch. Each call hits the underlying layer orchestrators, which keep their own 24-hour response cache (local disk, plus a shared Redis tier in production). The ttl_seconds hint is for the caller’s own cache layer.

Body

application/json
lat
number
required
lng
number
required
fields
string[] | null
preset
enum<string> | null
Available options:
terrain,
flood_risk,
wildfire_underwrite,
land_cover,
site_selection,
building_lookup,
points_of_interest,
utilities,
boundaries,
solar_siting,
wind_siting,
storage_siting,
data_center_siting,
grid_interconnect,
natural_hazard

Response

Successful Response