Backend Examples
Every PickPoint API call requires an X-Api-Key header. That key is the credential to your account - it controls billing, rate limits, and access. If it leaks, anyone can use your quota until you notice and rotate the key.
The correct architecture
Your backend holds the PickPoint key and acts as a proxy. Clients authenticate against your backend using your own auth system (JWT, session cookie, OAuth token). Your backend validates the request, calls PickPoint, and returns the result.
Geocoding & Routing
Device Tracking
What you get beyond security
- Rate limiting per user. Throttle individual users before they hit your PickPoint quota. One misbehaving client can't exhaust everyone's allowance.
- Response caching. Geocoding output for a given address is stable - coordinates don't change unless OSM data changes. Cache them in Redis, Postgres, or even in-process memory. Repeat calls return instantly with zero API cost.
- Audit log. Record every request - user ID, endpoint, query, timestamp, response latency - without any PickPoint involvement. Essential for debugging, billing reconciliation, and compliance.
- Key rotation without client updates. When you rotate the PickPoint key, only the server env var changes. No app store release, no forced update, no coordination with mobile clients.
Device tracking - two different auth models
Tracking is the one area where the rule is more nuanced, because PickPoint uses two separate authentication schemes:
| Role | Credentials | Can use from client? |
|---|---|---|
| Device (sends location) | client-id + client-secret - per-device credentials, not the account key | β Yes - safe to embed in mobile/IoT firmware |
| Subscriber (receives live feed) | x-api-key - the account API key | β No - must stay on your backend |
A device's client-secret only lets that specific device stream its own location. Even if it leaks, an attacker can only impersonate that one device - they cannot access other devices, history, or any other API. Rotate the device credentials if a device is lost or compromised.
For subscriber dashboards, the backend integration pattern applies: your backend holds the API key, subscribes to PickPoint's WebSocket, and fans events out to authenticated browser clients.
Security checklist
- Store
PICKPOINT_KEYin an environment variable, never in source code. - Add
.envto.gitignore- and verify it's there before the first commit. - Use separate keys for development, staging, and production so a staging breach doesn't affect production.
- Set up usage alerts in your PickPoint dashboard - an unexpected spike is the first sign of a leaked key.
- Rotate the key immediately if you suspect exposure. Rotation takes effect instantly on PickPoint's side.
- Configure CORS on your proxy so only your frontend origins can call it.
Proxy endpoint reference
| Your endpoint | Method | PickPoint API |
|---|---|---|
/geo/forward | GET | /v2/geocode/forward |
/geo/reverse | GET | /v2/geocode/reverse |
/geo/search | GET | /v2/address/search |
/route | POST | /v2/route |
/route/optimized | POST | /v2/route/optimized |
/devices | GET | /v2/devices |
/devices/:uid/tracks | GET | /v2/devices/:uid/tracks |
/tracking-relay | WS | wss://ws.pickpoint.io (subscriber) |
Node.js / ExpressPython / FastAPIRuby / SinatraGoJava / Spring Boot