SER™ API Developer Documentation

Everything needed to make the first authenticated SER™ request, understand the response, and avoid the usual developer-console maze.

Overview

SER™ is Spatial Evidence Resolution: the process of transforming real-world, ambiguous, partial, or noisy location input into structured, auditable spatial evidence.

It is not commodity geocoding and not a best-match lookup. SER™ returns evidence: candidates, confidence, ambiguity, geometry classes, GIDs, SHA-256 audit keys, and explanations.

Public endpoint

Customer calls go to:
https://travelsafepilot.com/api/v1/ser

Quickstart
  1. 1.Sign in or create one TravelSafePilot account.
  2. 2.Activate a SER™ plan from the API platform page.
  3. 3.Create an API key in the developer console.
  4. 4.Copy the key once when it is shown.
  5. 5.Make the first request.
curl "https://travelsafepilot.com/api/v1/ser?q=magic%20roundabout%20swindon&country_hint=gb" \
  -H "Authorization: Bearer YOUR_API_KEY"

Keep API keys server-side. Do not place keys in browser JavaScript, mobile binaries, public repositories, or client-visible logs.

Authentication

API requests use bearer API keys:

Authorization: Bearer YOUR_API_KEY

Dashboard sign-in and API request authentication are different surfaces. The dashboard uses your TravelSafePilot account session; the SER™ endpoint uses the API key.

Keys are tied to the canonical account and active entitlement state.

Request format

Version: v1

Methods: GET and POST

GET: /api/v1/ser?q=magic%20roundabout%20swindon&country_hint=gb

POST body: JSON with q or query, plus optional country_hint.

Accepted inputs: roads, intersections, traffic circles, roundabouts, route markers, landmarks, single points, and messy incident-style location text.

Successful response example
Query: magic roundabout swindon with country_hint=gb
{
  "ok": true,
  "product": "SER",
  "version": "v1",
  "query": {
    "raw": "magic roundabout swindon",
    "normalized": "magic roundabout swindon",
    "country_hint": "gb"
  },
  "resolution": {
    "mode": "forward",
    "reason": "candidates_found",
    "ambiguous": false,
    "candidate_count": 3,
    "returned_count": 3
  },
  "top_candidate": {
    "rank": 1,
    "decision_role": "selected",
    "match_type": "poi_cluster",
    "gid": "2bc1a25c-cfe6-541d-a208-a9ba5919b6e5",
    "candidate_sha256": "a4661d5c61b28181169521c27e4e01f0a474e6e94b66e34c1888e91d2429e355",
    "software_version": "ser-v1",
    "location": {
      "lat": 51.56283512444738,
      "lon": -1.7714570916666663,
      "geometry_class": "junction_complex"
    },
    "context": {
      "label": "The Magic Roundabout, gb",
      "country_key": "gb",
      "feature_kind": "roundabout"
    },
    "score": {
      "value": 20.9626929266307,
      "band": "very_high",
      "ambiguous": false,
      "candidate_count": 3,
      "score_spread": 12.6626929266307,
      "disqualified": false
    },
    "explain_human": "Candidates found - high confidence match"
  },
  "audit": {
    "response_sha256": "example-response-hash",
    "log_sha256": "example-log-integrity-hash",
    "software_version": "ser-v1"
  },
  "candidates": []
}

SHA-256 values are audit identifiers. They allow the candidate, response, log integrity record, and software version to be tied back to the exact decision path used at query time.

Interpreting SER™ output

GID is the candidate identifier used for traceability.

Candidate SHA-256 binds a returned candidate to the resolved evidence state.

Response/log SHA-256 helps prove the audit record has not been silently altered.

Software version records which SER™ engine version performed the query.

Candidates are ordered interpretations. Alternatives preserve meaningful competing evidence where exposed.

Confidence values and bands are evidence signals, not guarantees.

Ambiguity must be treated as operationally meaningful. A low-confidence or ambiguous result should not be handled like a clean address match.

Geometry class describes the type of evidence: point, segment, corridor, area, junction, or unresolved interpretation.

Example inputs
magic roundabout swindon · country_hint=gb
Roundabout / complex-junction evidence
oxford street and regent street london · country_hint=gb
Intersection evidence in a dense place-name environment
n1 km 45 · country_hint=za
Route-marker style evidence
m4 main road near km 12 cape town · country_hint=za
Long-road and marker ambiguity
accident near big circle by shell garage m4 jhb side · country_hint=za
Messy incident-style language
Errors and recovery
200
SER™ response returned
The request was accepted and SER™ returned a governed response. The payload may still show ambiguity, alternatives, weak confidence, or unresolved evidence.
400
Malformed request
The request is missing a usable query, has invalid JSON, or does not match the supported request shape.
401
Missing or invalid API key
Add the Authorization bearer header or rotate the key from the developer console.
403
Insufficient entitlement
The key/account was recognized, but live SER™ access is not active for the account or plan state.
404
Unsupported route
Use the current public endpoint: /api/v1/ser.
409
State conflict
Reserved for account, key, or idempotency conflicts where a requested state transition cannot be safely completed.
429
Rate or usage limit reached
The key/account has reached a limit for the active plan window. Back off, inspect usage, or upgrade the plan.
5xx
Transient service failure
A downstream or gateway failure occurred. Retry safely; do not treat the returned error as a valid spatial decision.
Usage, limits, and audit posture

SER™ requests are authenticated, entitlement-checked, classified, metered, and logged through the TravelSafePilot public gateway.

Usage is counted against Included SER™ queries per billing month for the active plan.

Public responses do not expose internal tables, internal hosts, stack traces, or raw internal model secrets.

Commercial request evidence is audit-oriented and does not log plaintext API keys.

Versioning and changelog

Current public SER™ endpoint version: v1.

Breaking public API changes require documentation updates before release.

Undocumented shadow routes are not part of the public developer contract.

Support and policy links

For integration support, enterprise review, or unusual request patterns, use the public contact path.