Authentication

All routes under /v1/ require a valid API key, except:

• GET / (root)
• GET /v1/health
• GET /v1/images/plane remains accessible without a key but returns a watermarked image instead of the normal one.

Supported modes

The API accepts the key via three mechanisms, in this order of precedence:

1. x-api-key header (recommended)

GET /v1/images/plane?plane=A320 HTTP/1.1
Host: api.aeromodel.dash-systems.fr
x-api-key: a3f02b1c9e8d7c6b5a4f3e2d1c0b9a8f7e6d5c4b3a2f1e0d

2. Authorization: Bearer header

Authorization: Bearer a3f02b1c9e8d7c6b5a4f3e2d1c0b9a8f7e6d5c4b3a2f1e0d

3. api-key URL query (discouraged)

https://api.aeromodel.dash-systems.fr/v1/images/plane?plane=A320&api-key=a3f...

⚠️ Appears in server logs, browser history, HTTP Referer. Avoid in production. Convenient only to embed an image in a static <img src> HTML tag without JS.

Responses without a key

The watermark image carries the headers x-auth-status: unauthorized and x-image-source: watermark-overlay.

Best practices

• Do not commit the key to a Git repository. Use environment variables or a secret manager.
• Use one key per environment (dev / staging / prod) to track usage.
• Periodic rotation: regenerate the key every 6-12 months.
• Browser side: route through a backend proxy when possible to avoid exposing the key in client code.

Request / regenerate a key

A key is managed as a Cloudflare Worker secret:

npx wrangler secret put API_KEYS

Multiple keys can coexist (comma separator). See api/DEPLOY.md on the maintenance side.