A browser-based proof of concept can call public APIs directly, but it is not a safe production architecture. Any key placed in HTML or JavaScript can be inspected by the end user. Minification, hidden fields and disabled developer tools do not make browser code secret.
Keep providers behind the server
The browser should send only business inputs such as location, radius and domain lens. The server should decide which providers to call, add credentials, transform responses, calculate signals and return a limited result object.
This protects credentials and also keeps scoring rules, weights and provider fallback logic outside the downloadable frontend.
Use a provider-specific queue
Public APIs rarely share the same rate limit. Geocoding services may require one request per second, while weather providers allow greater concurrency. A queue should control:
- Maximum concurrent requests per provider.
- Minimum time between request starts.
- Timeouts and cancellation.
- Retry policy for temporary failures.
- Priority for interactive requests.
Cache by geography and request type
Many geospatial inputs change slowly. Soil, administrative context and macro indicators can be cached for hours or days. Weather and air quality need shorter lifetimes. Caching reduces cost, improves response time and protects providers from repeated calls for the same location.
Never build an open proxy
A generic endpoint that accepts any URL from the browser can be abused to reach unapproved systems. The server should use a strict provider allowlist or, preferably, expose purpose-built routes such as /api/analyze that do not accept an external target URL at all.
The safest provider URL is the one the browser never controls.
Separate missing data from fallback data
When a provider fails, the application should not silently inject a pre-defined “average” score. It should mark the signal unavailable, lower weighted coverage and explain what evidence is missing. Clearly labelled proxy data can be used, but it must not masquerade as a direct measurement.
Add application-level protection
- Per-IP demo rate limits.
- Payload size and input validation.
- Security headers and a restrictive Content Security Policy.
- Redaction of provider errors and credentials.
- Request identifiers and structured logs.
- Environment variables for all secrets.
The result
A queue-based backend does more than hide keys. It creates a controlled boundary between the customer experience and an unpredictable collection of third-party services. That boundary is essential for reliability, security and explainability.