@palbase/backend 38.0.3 → 38.0.4

package/docs/auth.md

@@ -56,13 +56,17 @@ mid-session keeps reporting `false` until their next token. `roles` is the
 exception, and deliberately so — it is read from the table on every request, so
 a grant or a revocation lands immediately.
 
-**"Their next token" arrives on its own.** A refresh re-reads the row when it
-mints, so the rotated token carries the verification that just happened — and
-the client SDKs spend that refresh for you: they rotate when `refreshUser()`
-sees the flag flip, and a `403 email_not_verified` earns one renew-and-replay
-the way a 401 does. Nobody has to sign out and back in. If you are holding a
-token yourself — a server-to-server caller, a script — call `POST /auth/refresh`
-and use what comes back.
+**"Their next token" is a refresh away — not a sign-in.** `POST
+/auth/token/refresh` re-reads the row when it mints, so the rotated token
+carries the verification that just happened. Signing out and back in is never
+the remedy.
+
+The mobile SDKs spend that refresh for you — iOS from Palbe 0.57.0, Android
+from 2.1.0. Both rotate when `refreshUser()` sees the flag flip, and both give
+a `403 email_not_verified` one renew-and-replay, the way a 401 already gets
+one. On any other caller — a web client, a script, a server-to-server
+integration — do it yourself: call `POST /auth/token/refresh` with the refresh
+token and use the pair that comes back.
 
 ## Roles and permissions
 

package/docs/llms-full.txt

@@ -832,13 +832,17 @@ mid-session keeps reporting `false` until their next token. `roles` is the
 exception, and deliberately so — it is read from the table on every request, so
 a grant or a revocation lands immediately.
 
-**"Their next token" arrives on its own.** A refresh re-reads the row when it
-mints, so the rotated token carries the verification that just happened — and
-the client SDKs spend that refresh for you: they rotate when `refreshUser()`
-sees the flag flip, and a `403 email_not_verified` earns one renew-and-replay
-the way a 401 does. Nobody has to sign out and back in. If you are holding a
-token yourself — a server-to-server caller, a script — call `POST /auth/refresh`
-and use what comes back.
+**"Their next token" is a refresh away — not a sign-in.** `POST
+/auth/token/refresh` re-reads the row when it mints, so the rotated token
+carries the verification that just happened. Signing out and back in is never
+the remedy.
+
+The mobile SDKs spend that refresh for you — iOS from Palbe 0.57.0, Android
+from 2.1.0. Both rotate when `refreshUser()` sees the flag flip, and both give
+a `403 email_not_verified` one renew-and-replay, the way a 401 already gets
+one. On any other caller — a web client, a script, a server-to-server
+integration — do it yourself: call `POST /auth/token/refresh` with the refresh
+token and use the pair that comes back.
 
 ## Roles and permissions
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@palbase/backend",
-  "version": "38.0.3",
+  "version": "38.0.4",
   "description": "Palbase Backend SDK — class controllers (@Controller/@Get/@Post + @Body/@QueryParams/@Param), error classes, schema DSL",
   "license": "MIT",
   "repository": {