Simplify setup flow and public API docs

README.md

@@ -17,7 +17,7 @@ If you want a lightweight DuckDNS / Dynu / No-IP style service that you control
 - **CNAME alias support**: users create one KarlDNS hostname, then point `home.example.com` to it at their own DNS provider.
 - **Real DNS publishing** through **Cloudflare** or **RFC 2136** with A and AAAA support.
 - **Small-server friendly**: FastAPI, SQLite WAL, simple Docker deployment, and no heavy background platform.
-- **API first**: small built-in API guide, OpenAPI JSON, and endpoints under `/api/v1`.
+- **API first**: small built-in API guide, public OpenAPI JSON, and endpoints under `/api/v1`.
 
 ## Screenshots
 
@@ -44,7 +44,7 @@ KarlDNS lets you host your own managed DynDNS service:
 
 1. A user opens your KarlDNS URL.
 2. They generate a random hostname like `a1b2c3d4.karldns.de`.
-3. KarlDNS shows the exact router settings and one-time secrets.
+3. KarlDNS shows the exact router settings and private values.
 4. The user confirms they saved the values, which registers the hostname.
 5. The router periodically calls the update URL with its current public IPv4/IPv6 address.
 6. KarlDNS publishes the matching DNS records through your configured DNS backend.
@@ -71,7 +71,7 @@ That means users always have a current hostname for VPN, remote access, self-hos
 | Generated hostnames | Random provider-owned names that can be used directly or as CNAME targets |
 | User-owned DNS names | CNAME only. KarlDNS publishes the generated provider-owned hostname; the user's DNS provider serves the alias |
 | Persistence | SQLite with WAL mode |
-| API | FastAPI, small API docs page, OpenAPI JSON |
+| API | FastAPI, small API docs page, public OpenAPI JSON |
 | Auth model | No user accounts. Private bearer links for hostnames and dashboards |
 | Operations | Rate limiting, admin audit views, update logs, cleanup jobs, Docker, Caddy example |
 
@@ -106,7 +106,7 @@ Open:
 
 Admin auth uses HTTP Basic auth. The username can be any value; the password is `DDNS_ADMIN_PASSWORD`.
 
-The API guide documents the public endpoints plus the authenticated operator API. OpenAPI JSON remains available for tools.
+The API guide and OpenAPI JSON document the user and router endpoints only. Admin endpoints stay authenticated and are not exposed in the public schema.
 
 ## Production Setup
 
@@ -283,7 +283,7 @@ The generated hostname is not a secret. Treat it like any public DNS name. The u
 
 ## HTTP API
 
-The JSON API is available under `/api/v1`. The public API has three surfaces: admin data, user dashboard data with history, and router registration/update calls.
+The JSON API is available under `/api/v1`. The public API has two surfaces: user dashboard data with history and router registration/update calls.
 
 | Endpoint | Purpose |
 | --- | --- |
@@ -293,10 +293,6 @@ The JSON API is available under `/api/v1`. The public API has three surfaces: ad
 | `DELETE /api/v1/hostnames/{dashboard_secret}` | Delete a hostname and its DNS records. |
 | `GET or POST /api/v1/router/register/{dashboard_secret}` | Register a pending hostname after secrets are saved. |
 | `GET or POST /api/v1/router/update/{update_secret}` | Update a hostname from FRITZ!Box, another router, curl, or a cron script. |
-| `GET /api/v1/admin/dashboard` | Authenticated operator summary, metrics, cleanup state, and recent history. |
-| `GET /api/v1/admin/events` | Authenticated paginated update history. |
-| `GET /api/v1/admin/hostnames` | Authenticated paginated hostname inventory. |
-| `GET /api/v1/admin/records` | Authenticated paginated DNS record inventory. |
 
 Example:
 
@@ -314,13 +310,6 @@ curl -sS -X POST https://karldns.de/api/v1/hostnames/<dashboard-secret>/rotate-u
 
 The response contains a replacement `update_url`. The old update URL stops working immediately.
 
-Operator API calls use the same HTTP Basic auth password as the admin UI:
-
-```bash
-curl -sS -u admin:<admin-password> https://karldns.de/api/v1/admin/dashboard
-curl -sS -u admin:<admin-password> 'https://karldns.de/api/v1/admin/events?limit=25'
-```
-
 ## Docker
 
 Copy the example environment file and replace every placeholder:
@@ -349,7 +338,7 @@ The default container command runs one Uvicorn worker. Keep that deployment shap
 - Use a least-privilege DNS API token or TSIG key.
 - Set `DDNS_TRUSTED_HOSTS` only when the app should answer for hostnames beyond `DDNS_PUBLIC_BASE_URL`.
 - Configure `DDNS_TRUSTED_PROXY_IPS` only for reverse proxies that strip user-supplied forwarding headers.
-- Keep `/docs` available if you want the small developer surface. Operator API routes are documented and require Basic auth; admin UI form routes stay hidden.
+- Keep `/docs` available if you want the small developer surface. It documents only the public user and router endpoints.
 - Leave cleanup enabled. The cleanup scheduler is stored in SQLite with a task row, next run time, status, last error, and a database lease so only one app process runs a due cleanup job.
 - Back up `/data/ddns.sqlite3`.
 - Run one Uvicorn worker with SQLite unless you have tested your deployment under load. Scheduled cleanup is lease-protected across workers, but rate-limit state and per-host update locks are process-local.