@palbase/backend 14.3.0 → 15.0.0

package/dist/test/index.d.cts

@@ -1,4 +1,4 @@
-import { D as DBClient, P as PBRequest, a as PalbaseModuleClients, L as Logger, C as CacheClient, U as User } from '../endpoint-BG-JVUPL.cjs';
+import { D as DBClient, P as PBRequest, a as PalbaseModuleClients, L as Logger, C as CacheClient, U as User } from '../endpoint-BW8bn1y-.cjs';
 import 'zod';
 
 /** Mock DB client with tracking and seed data support. */

package/dist/test/index.d.ts

@@ -1,4 +1,4 @@
-import { D as DBClient, P as PBRequest, a as PalbaseModuleClients, L as Logger, C as CacheClient, U as User } from '../endpoint-BG-JVUPL.js';
+import { D as DBClient, P as PBRequest, a as PalbaseModuleClients, L as Logger, C as CacheClient, U as User } from '../endpoint-BW8bn1y-.js';
 import 'zod';
 
 /** Mock DB client with tracking and seed data support. */

package/docs/auth.md

@@ -128,6 +128,43 @@ Or declare it on the route and let the runtime enforce it:
 Unverified callers get `403 email_not_verified`. Use the route flag to fence a
 whole controller, and the inline check when only part of a handler cares.
 
+## Social sign-in and account linking
+
+Signing in with Google or Apple is a client flow — the Web and iOS SDK docs
+cover the redirect and code-exchange calls. The part your backend cares about
+is which `user.id` comes out of it, because that id is what every row you wrote
+is keyed on.
+
+**One address, one account.** If someone signs up with `a@x.com` + password and
+later signs in with Google on the same address, they land on the **same
+`user.id`**, in the same session, with all their data. Palbase links the Google
+identity onto the existing account instead of creating a second one. A second
+account on the same address is not merely avoided — it is impossible: the email
+is uniquely indexed.
+
+The link happens only when the provider asserts the address is verified
+(`email_verified`). If it does not, and the address already belongs to an
+account, sign-in is refused with `409 email_already_registered` rather than
+silently landing somewhere new.
+
+**Linking into an unverified account clears its password.** An account whose
+email was never verified could have been registered by anyone — including
+someone who does not own the address. When a provider proves ownership and
+links in, the untrusted password is removed and any session opened with it is
+revoked. `@User()` still resolves to the same id, so your data keeps working;
+the user simply no longer has a password until they set one.
+
+**Going the other way** — a user who started with Google and now wants a
+password — is the password *reset* flow, not `updatePassword`. There is no
+current password to supply, so `updatePassword` fails; `resetPassword(email)`
+followed by `confirmPasswordReset` sets the first one. Note that completing it
+signs the user out everywhere.
+
+To render the right form, ask the client SDK which credentials the account has
+(`pb.auth.getSignInMethods()` in `@palbase/web`) — it reports whether a local
+password exists and which providers are linked, so a Google-only user is never
+shown a password field they cannot fill.
+
 ## Password reset and magic links
 
 Both are client-driven and need no backend code: the client SDK calls the auth

package/docs/llms-full.txt

@@ -772,6 +772,43 @@ Or declare it on the route and let the runtime enforce it:
 Unverified callers get `403 email_not_verified`. Use the route flag to fence a
 whole controller, and the inline check when only part of a handler cares.
 
+## Social sign-in and account linking
+
+Signing in with Google or Apple is a client flow — the Web and iOS SDK docs
+cover the redirect and code-exchange calls. The part your backend cares about
+is which `user.id` comes out of it, because that id is what every row you wrote
+is keyed on.
+
+**One address, one account.** If someone signs up with `a@x.com` + password and
+later signs in with Google on the same address, they land on the **same
+`user.id`**, in the same session, with all their data. Palbase links the Google
+identity onto the existing account instead of creating a second one. A second
+account on the same address is not merely avoided — it is impossible: the email
+is uniquely indexed.
+
+The link happens only when the provider asserts the address is verified
+(`email_verified`). If it does not, and the address already belongs to an
+account, sign-in is refused with `409 email_already_registered` rather than
+silently landing somewhere new.
+
+**Linking into an unverified account clears its password.** An account whose
+email was never verified could have been registered by anyone — including
+someone who does not own the address. When a provider proves ownership and
+links in, the untrusted password is removed and any session opened with it is
+revoked. `@User()` still resolves to the same id, so your data keeps working;
+the user simply no longer has a password until they set one.
+
+**Going the other way** — a user who started with Google and now wants a
+password — is the password *reset* flow, not `updatePassword`. There is no
+current password to supply, so `updatePassword` fails; `resetPassword(email)`
+followed by `confirmPasswordReset` sets the first one. Note that completing it
+signs the user out everywhere.
+
+To render the right form, ask the client SDK which credentials the account has
+(`pb.auth.getSignInMethods()` in `@palbase/web`) — it reports whether a local
+password exists and which providers are linked, so a Google-only user is never
+shown a password field they cannot fill.
+
 ## Password reset and magic links
 
 Both are client-driven and need no backend code: the client SDK calls the auth
@@ -1504,13 +1541,46 @@ const { data: doc } = await Documents.doc("rooms/abc").get();
 
 ## Notifications
 
+**No provider setup is required.** Every project starts with a managed sender, so
+email and SMS deliver on a brand-new project with no provider, no API key, and no
+`config/notifications.ts`. You configure your own provider only to send from your
+own domain — see [Config](./config.md).
+
 ```ts
 import { Notifications } from "@palbase/backend";
-await Notifications.email.send({ /* PalbaseEmailSendParams */ });
-await Notifications.push.send({ /* PalbasePushSendParams */ });
-await Notifications.sms.send({ /* PalbaseSmsSendParams */ });
+
+// Email — `to` takes one address or many.
+await Notifications.email.send({
+  to: user.email,
+  subject: "Your receipt",
+  html: "<p>Thanks!</p>",          // or `text`, or a server template:
+});
+await Notifications.email.send({
+  to: user.email,
+  templateSlug: "receipt",         // defined in config/notifications.ts
+  locale: "tr",                    // without this the extra locale rows are unreachable
+  variables: { total: "₺240" },
+});
+
+// Push — `to` is a device token, a list of them, or { topic }.
+await Notifications.push.send({
+  to: { topic: "announcements" },
+  title: "Deploy finished",        // string, or a { "en": …, "tr": … } locale map
+  body: "Your backend is live.",
+  deep_link: "todoapp://deploys",
+});
+
+// SMS — `body` and `templateSlug` are mutually exclusive.
+await Notifications.sms.send({ to: user.phone, body: "Your code is 123456" });
 ```
 
+A send that no provider can carry is rejected on the request itself with
+`provider_not_configured` — it is never accepted and then dropped, so a
+successful call means a real sender took the message.
+
+`Notifications` also carries `verify` (phone OTP send/check), `inbox` (in-app
+messages), and `registerDevice` / `unregisterDevice` for push tokens.
+
 ## Flags
 
 ```ts

package/docs/services.md

@@ -75,13 +75,46 @@ const { data: doc } = await Documents.doc("rooms/abc").get();
 
 ## Notifications
 
+**No provider setup is required.** Every project starts with a managed sender, so
+email and SMS deliver on a brand-new project with no provider, no API key, and no
+`config/notifications.ts`. You configure your own provider only to send from your
+own domain — see [Config](./config.md).
+
 ```ts
 import { Notifications } from "@palbase/backend";
-await Notifications.email.send({ /* PalbaseEmailSendParams */ });
-await Notifications.push.send({ /* PalbasePushSendParams */ });
-await Notifications.sms.send({ /* PalbaseSmsSendParams */ });
+
+// Email — `to` takes one address or many.
+await Notifications.email.send({
+  to: user.email,
+  subject: "Your receipt",
+  html: "<p>Thanks!</p>",          // or `text`, or a server template:
+});
+await Notifications.email.send({
+  to: user.email,
+  templateSlug: "receipt",         // defined in config/notifications.ts
+  locale: "tr",                    // without this the extra locale rows are unreachable
+  variables: { total: "₺240" },
+});
+
+// Push — `to` is a device token, a list of them, or { topic }.
+await Notifications.push.send({
+  to: { topic: "announcements" },
+  title: "Deploy finished",        // string, or a { "en": …, "tr": … } locale map
+  body: "Your backend is live.",
+  deep_link: "todoapp://deploys",
+});
+
+// SMS — `body` and `templateSlug` are mutually exclusive.
+await Notifications.sms.send({ to: user.phone, body: "Your code is 123456" });
 ```
 
+A send that no provider can carry is rejected on the request itself with
+`provider_not_configured` — it is never accepted and then dropped, so a
+successful call means a real sender took the message.
+
+`Notifications` also carries `verify` (phone OTP send/check), `inbox` (in-app
+messages), and `registerDevice` / `unregisterDevice` for push tokens.
+
 ## Flags
 
 ```ts

package/package.json

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