From 66d0c0905338dcfaef2d1e61bf1664df8a02b49e Mon Sep 17 00:00:00 2001 From: Motrotz Date: Sun, 18 Jan 2026 11:05:36 +0100 Subject: [PATCH 1/5] Fix JWT token 'sub' claim format The actual token returned by The SSO endpoint and used by Applications, including the official API Explorer at https://developers.eveonline.com/api-explorer has this format. --- docs/services/sso/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/services/sso/index.md b/docs/services/sso/index.md index 8136f73b..c404b8ca 100644 --- a/docs/services/sso/index.md +++ b/docs/services/sso/index.md @@ -206,7 +206,7 @@ The `exp` claim in the JWT token is the expiration time of the token, represente Now that you have verified the JWT Token, you can use the claims belonging to the token to get more information about the access the token has, and for whom it was issued. -The `sub` claim in the JWT token is in the format of `EVE:CHARACTER:` and can be used to get the current character's ID. The `name` claim contains the character's name, and the `scp` claim is an array of scopes that have been granted to this token. +The `sub` claim in the JWT token is in the format of `CHARACTER:EVE:` and can be used to get the current character's ID. The `name` claim contains the character's name, and the `scp` claim is an array of scopes that have been granted to this token. ## Log in with EVE Online buttons From e19dfbc632935eba0360d07a9e27881a40c6b6ac Mon Sep 17 00:00:00 2001 From: Motrotz Date: Sun, 18 Jan 2026 22:44:48 +0100 Subject: [PATCH 2/5] Update rate-limiting documentation for clarity Clarify that new rate limiting headers are mutually exclusive to Error Limit documentation. --- docs/services/esi/rate-limiting.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/services/esi/rate-limiting.md b/docs/services/esi/rate-limiting.md index f36554a6..28dbb295 100644 --- a/docs/services/esi/rate-limiting.md +++ b/docs/services/esi/rate-limiting.md @@ -16,6 +16,7 @@ In most cases you should be fine with far less requests than the rate limit allo For routes that do not have this new rate limiting enabled, there is still an older "error rate limit" active. This allows at most 100 non-2xx/3xx responses per minute. After that, it will return 420s on all ESI routes, even those with the new rate limiting enabled. + The headers described in this document are mutually exclusive to those described in the Error Limit documentation. !!! important From ef96337a4c6747261d369e31d2ac8d0904e76505 Mon Sep 17 00:00:00 2001 From: Motrotz Date: Sun, 18 Jan 2026 22:49:10 +0100 Subject: [PATCH 3/5] Enhance ESI error limit explanation --- docs/services/esi/best-practices.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/services/esi/best-practices.md b/docs/services/esi/best-practices.md index 4aa288f4..6f022ae9 100644 --- a/docs/services/esi/best-practices.md +++ b/docs/services/esi/best-practices.md @@ -73,12 +73,14 @@ Not abiding to the information transmitted can lead to your app being **banned** ### Error limit -ESI limits how many errors you’re allowed to get within a set time frame. Once you reach the error limit, all your request are automatically discarded until the end of the time frame. +ESI limits how many errors you’re allowed to get within a set time frame. This Limit uses a fixed time frame, in contrast to the Bucket Limit which is a sliding window. Once you reach the error limit, all your request are automatically discarded until the end of the time frame. Error limit headers: `X-ESI-Error-Limit-Remain` errors left in this time frame. `X-ESI-Error-Limit-Reset` seconds left until next time frame and errors reset to zero. +These headers are mutually exclusive to those described in the Bucket based Rate Limit. + The details are explained in this blog post: [Error Rate Limiting](/blog/error-rate-limiting-imminent) ### Bucket Limit From 18be70984a70fef0e9301f20f78949767ccca6b0 Mon Sep 17 00:00:00 2001 From: Motrotz Date: Sun, 18 Jan 2026 22:59:17 +0100 Subject: [PATCH 4/5] Update documentation for rate limiting headers --- docs/services/esi/rate-limiting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/services/esi/rate-limiting.md b/docs/services/esi/rate-limiting.md index 28dbb295..3e1e5fb1 100644 --- a/docs/services/esi/rate-limiting.md +++ b/docs/services/esi/rate-limiting.md @@ -16,7 +16,7 @@ In most cases you should be fine with far less requests than the rate limit allo For routes that do not have this new rate limiting enabled, there is still an older "error rate limit" active. This allows at most 100 non-2xx/3xx responses per minute. After that, it will return 420s on all ESI routes, even those with the new rate limiting enabled. - The headers described in this document are mutually exclusive to those described in the Error Limit documentation. + The headers described in this document are mutually exclusive to those described in the Error Limit documentation found under "Best Practices". !!! important From 8e0817b04f2001a6d31d4d873cc3c577c5100cc6 Mon Sep 17 00:00:00 2001 From: Motrotz Date: Sun, 18 Jan 2026 23:00:38 +0100 Subject: [PATCH 5/5] Add note on Error Limiting best practices --- docs/services/esi/rate-limiting.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/services/esi/rate-limiting.md b/docs/services/esi/rate-limiting.md index 3e1e5fb1..82cf1617 100644 --- a/docs/services/esi/rate-limiting.md +++ b/docs/services/esi/rate-limiting.md @@ -98,3 +98,4 @@ Each route in the same group will show the same `window-size` and `max-tokens`. - If you need to burst, that is fine; just not every window-size. - Use staggered scheduling for periodic requests when possible. Ideally not `*/5` cronjobs. But rather: 5 minutes after the last job was finished. - Respect cache times to minimize unnecessary requests. +- For Error Limiting, see [Best Practices](./best-practices.md)