Reloquent
DOCS · RLQ · SPATIAL ENRICHMENT API

RLQ documentation

Base URL https://enrich.reloquent.ai. Every /v1/* route needs a bearer key; /health does not. Coordinates are WGS84. Units are metric throughout.

Authentication

Send your key as Authorization: Bearer rlq_live_.... Keys come in two flavours — rlq_live_ for production and rlq_test_ for development. They behave identically; the split exists so you can tell your traffic apart in logs and revoke one without touching the other.

Keys are stored hashed. The plaintext is shown once, at issue, and is never recoverable — treat it like a password. Lost a key? Rotate it from the dashboard; a grace rotation leaves the old key working for 24 hours so you can roll a deployment without downtime. A missing or invalid token is 401.

Quickstart

Enrichment is asynchronous: the POST returns immediately with a job id, so one point and a ten-thousand-vertex track use the same code path.

CURL
curl -sS -X POST https://enrich.reloquent.ai/v1/enrich \
  -H "Authorization: Bearer $RLQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"geojson":{"type":"FeatureCollection","features":[
       {"type":"Feature",
        "geometry":{"type":"Point","coordinates":[-119.5383,37.8651]},
        "properties":{"name":"Yosemite Valley"}}]}}'

# 202 Accepted -- enrichment is asynchronous
{ "job_id": "2a29722c-...", "status": "queued", "credits": 1,
  "links": { "status_url": "...", "events_url": "...", "download_url": "..." } }

The response carries job_id, a status, the job's credits, and links for status, events and download. Poll the status link, or subscribe to the events link and wait to be told. When the job succeeds, fetch the download link once.

GPX

CURL · MULTIPART
curl -sS -X POST https://enrich.reloquent.ai/v1/enrich \
  -H "Authorization: Bearer $RLQ_API_KEY" \
  -F "gpx=@track.gpx"

# GPX in, GPX out -- the output format is bound when the job is enqueued.

Routes

The whole public surface.

ROUTEWHAT IT DOES
POST /v1/enrich Enqueue a job. Returns 202 with a job id, its credit cost and links. GeoJSON body, or multipart with a gpx file field.
GET /v1/enrich/{id} Job status — queued, running, succeeded, failed — with progress and the download link when finished.
GET /v1/enrich/{id}/events The same lifecycle as server-sent events, if you would rather be told than poll.
GET /v1/enrich/{id}/download The enriched output, in the format the job was enqueued with.
GET /v1/sources The sources available to your key, with the role each one plays.
GET /health Liveness. The one route that needs no key.

Contract

Point and LineString geometries are supported, in GeoJSON or GPX. Coordinates are WGS84 (EPSG:4326); a third coordinate or a GPX <ele> passes through untouched, and RLQ's own terrain elevation is reported separately. Your properties are returned verbatim — enrichment is added alongside them under its own rlq key, never merged over them, and your geometry is never modified, simplified or snapped. Polygons are not supported.

What the output looks like

GEOJSON OUT · ONE FEATURE
{
  "type": "Feature",
  "geometry": { "type": "Point", "coordinates": [-111.615, 35.26] },
  "properties": {
    "user_label": "Schultz Pass",          // yours, untouched
    "rlq": {                                // ours, added alongside
      "padus": [{ "unit_name": "Coconino National Forest",
                  "manager_type": "FED", "designation_type": "NF", "public_access": "OA",
                  "decoded": { "manager_type": "Federal", "designation_type": "National Forest",
                               "public_access": "Open access" } }],
      "tiger_states": [{ "name": "Arizona", "statefp": "04" }]
    }
  }
}

One key per source that matched, under rlq. Each match carries the source's own fields, a distance_m where the query pattern has one (containment matches like this one carry none), a decoded block when a code has a label (so you never keep your own lookup tables), and a relevance score in [0, 1] on track and route matches. A source with no match is omitted. When a cap or a filter dropped matches that were found, the response says so: complete is false and omissions[] names the source and the cause.

Credits

The meter counts credits, tallied per UTC calendar month. A point is 1 credit; a line, track or route is 1 credit per 100 vertices, rounded up, minimum 1. A request consumes the sum of its features' credits, counted at acceptance, and a request that would exceed the remaining monthly cap is refused whole with 429 — never partially run, never billed. Live usage against your cap is on the dashboard; the caps per plan are on the pricing page.

Errors and limits

STATUSWHEN
400 Body missing or invalid geojson; a feature is not a Point or LineString; a control value is out of enum; or input_too_large, which names the threshold you crossed and what to do.
401 Missing or invalid Authorization header.
406 An Accept header was sent and no supported format satisfies it.
413 Body exceeds the maximum request size (50 MB).
415 Content-Type is neither application/json nor multipart/form-data.
429 Monthly credit cap reached, or the per-tier request rate exceeded. Calls are refused, never billed.
503 Transient upload failure — safe to retry.

Limits: 100,000 features per request and a 50 MB body. Reaching your monthly credit cap refuses further calls with 429 and a Retry-After rather than billing overage.

Attribution