TourismPulse

API reference

One endpoint. Query by state (and optionally a destination/county name), get back real published tourism-spending figures with a source citation and confidence flag — as JSON or a formatted PDF report.

Authentication

Pass your key as a bearer token, or in an x-api-key header. Generate keys from the dashboard.

Request

GET /api/v1/destination-impact?state=TN&destination=Knox
Authorization: Bearer tpx_live_...

Response

Append &format=pdf to get a formatted stakeholder report for the top matching record instead of JSON.

{
  "records": [
    {
      "state_code": "TN",
      "county_or_destination": "Knox County",
      "year": 2025,
      "visitor_spending_usd": 2208345965,
      "state_tax_revenue_usd": 139671017,
      "local_tax_revenue_usd": 81648077,
      "direct_jobs": null,
      "yoy_growth_pct": 3.9,
      "state_rank": 4,
      "source_url": "https://www.visitknoxville.com/articles/post/...",
      "source_format": "press-release",
      "source_vendor": "Tourism Economics",
      "extraction_confidence": "verified",
      "extraction_note": "Parsed from the standard Tourism Economics county press-release template."
    }
  ],
  "coverage": { "status": "verified", "notes": "..." },
  "usage": { "reports_used_this_period": 4, "monthly_quota": 200, "plan": "starter" }
}

Reading the coverage & confidence fields

Where the data comes from

Almost every state tourism office publishes some form of visitor-spending data, most commonly produced by the research firm Tourism Economics (an Oxford Economics company), but the format varies by state — a statewide PDF report, a per-county press release, a downloadable CSV, or an interactive dashboard with no stable export URL at all. TourismPulse normalizes whichever format a given state uses into one consistent schema. See /coverage for exactly which states are verified today.

Visitor positioning — proving impact vs. driving it

Everything above is retrospective: it proves what already happened, for an audience of funders. /api/v1/visitor-positioning is forward-looking instead — given a destination's coordinates, it returns real nearby points of interest (via OpenStreetMap's free Overpass API), the nearest major visitor gateway city with an estimated drive time, and an auto-written narrative paragraph combining both. Pass includePositioning=true&lat=..&lon=.. to the destination-impact endpoint's PDF export to get both halves — proof and positioning — in one document.

What the desirability score is, and isn't

This score measures visitability — how many things are nearby, how varied they are, and how easy the destination is to reach — combined with an optional real quality signal (aggregate ratings, via the official Google Places API only). It does not measure demand, search interest, or how many people currently want to visit. Review data in particular reflects people who already visited, not intent to visit — a real distinction worth keeping straight if you're using this score to argue for future visitor growth. Weights are documented in src/lib/geo/desirabilityScore.ts and meant to be tuned, not treated as scientifically derived.

One thing this project deliberately does not do: scrape Google reviews. Google's Terms of Service prohibit unauthorized scraping of review content, and doing so at the scale a commercial product needs is a real legal exposure, not a gray area. Any ratings signal here goes through the official, billed Places API under your own account instead.

Amenities & traffic — what's already there, and what already comes through

Pass includeAmenities=true and/or includeTraffic=true (alongside lat/lon) to the PDF export for a section on real nearby amenities and vehicle traffic exposure — useful for the same council/grant/press conversation the economic-impact report is already built for, but answering "what's actually here" and "how easy is this place to reach," not just "what did visitors spend."

Errors