^{Originally posted by Gitwhut May 13, 2026}

What went wrong?

Kobo sync stopped working. The Kobo device successfully hits /v1/initialization and gets a 200 response, but the response is incomplete - it only contains 2658 bytes and is missing critical resource URLs like library_sync, library_metadata, library_book, and reading_state. Because those URLs are missing, the Kobo never makes any further calls beyond initialization, so no books ever sync to the device.
Meanwhile, an identical request made via curl to the same /v1/initialization endpoint returns the full 11728-byte response with all library URLs correctly populated. Same URL, same token, same Traefik route, but the Kobo gets a stripped-down response and curl gets the full one.
The Grimmory log shows WARN o.b.s.kobo.KoboInitializationService : Unexpected response from Kobo /v1/initialization, fallback to noproxy every time the Kobo hits the endpoint, even with "Forward to Rakuten Kobo Store" turned OFF in admin settings.

How can we reproduce it?

1. Run Grimmory v3.0.3 behind Traefik reverse proxy with HTTPS
2. Set up Kobo sync for a non-admin user; assign them a Kobo shelf with EPUB books
3. Configure the Kobo's api_endpoint in .kobo/Kobo/Kobo eReader.conf to point at the Grimmory sync URL
4. Trigger sync on the Kobo
5. Observe in Traefik logs: Kobo hits /v1/initialization and gets 200 2658 bytes
6. Run curl against the same /v1/initialization endpoint from anywhere with the same token: returns 200 11728 bytes with full URL set
7. Inspect Kobo's conf file after sync: library_sync, library_metadata, library_book, reading_state are absent from [OneStoreServices]
8. Grimmory log shows: WARN o.b.s.kobo.KoboInitializationService : Unexpected response from Kobo /v1/initialization, fallback to noproxy

I verified via tcpdump between Traefik and the Grimmory container that the Kobo's request headers are identical to curl's (Host, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Port, User-Agent). Same Authorization Bearer behavior - curl gets 11728 bytes whether the Bearer header is present or not. HTTP/1.1 vs HTTP/2 also makes no difference (tested with curl --http1.1).
Toggling "Forward to Rakuten Kobo Store" off changes the response size from 2956 to 2658 bytes but does not include the missing library URLs.
Regenerating the sync token and re-pairing the Kobo did not help - same noproxy fallback occurs against the new token.

What Build of Grimmory are you on?

Stable

Your setup

• Host OS: Debian 12 VM
• Installation: Docker Compose via Portainer
• Image: grimmory/grimmory:latest (v3.0.3)
• Database: MariaDB via lscr.io/linuxserver/mariadb:11.4.5 on the same compose stack
• Reverse proxy: Traefik v3 with wildcard TLS via Let's Encrypt (Cloudflare DNS challenge)
• Authentication: Authentik OIDC for browser logins; OIDC native (not forward-auth) on Grimmory
• DNS: AdGuard Home (split DNS), wildcard internal domain → VM IP for internal traffic
• Kobo device: Kobo Touch firmware 4.38.23684
• Network: Both Grimmory and Traefik on shared external Docker network proxy
• Traefik labels: standard host routing, no Authentik middleware attached to Grimmory route
• Grimmory env: default; forward-headers-strategy: native is set in Grimmory's bundled application.yaml

Screenshots or error messages (optional)

Grimmory log:
WARN 1 --- [booklore-api] [mcat-handler-85] o.b.s.kobo.KoboInitializationService : Unexpected response from Kobo /v1/initialization, fallback to noproxy

Traefik access log showing the response size discrepancy:

From Kobo (HTTP/1.1):

<KOBO_IP> ... "GET /api/kobo//v1/initialization HTTP/1.1" 200 2658

From curl on same LAN (HTTP/2):

curl -s "https://<GRIMMORY_HOST>/api/kobo//v1/initialization" | wc -c

Returns: 11728

Kobo's [OneStoreServices] after sync — missing endpoints:
api_endpoint=https://<GRIMMORY_HOST>/api/kobo/
image_host=https://<GRIMMORY_HOST>
image_url_template=https://<GRIMMORY_HOST>/api/kobo//v1/books/.../image.jpg

library_sync, library_metadata, library_book, reading_state — all absent

Curl's full response includes those endpoints correctly:
"library_sync": "https://<GRIMMORY_HOST>/api/kobo//v1/library/sync"
"library_metadata": "https://<GRIMMORY_HOST>/api/kobo//v1/library/{Ids}/metadata"
"library_book": "https://<GRIMMORY_HOST>/api/kobo//v1/user/library/books/{LibraryItemId}"
"reading_state": "https://<GRIMMORY_HOST>/api/kobo//v1/library/{Ids}/state"

Before submitting

• I've searched existing discussions and this hasn't been reported yet
• I've reviewed this report and have completed it as fully as I can