brainerce 1.59.0 → 1.63.0

package/README.md

@@ -62,13 +62,14 @@ Every Brainerce storefront must include **all mandatory features** below. Featur
 | Login + verification branch                              | `client.loginCustomer()`                                                                                                                                     | ✅          |
 | Forgot / reset password                                  | `client.forgotPassword()`, `client.resetPassword()`                                                                                                          | ✅          |
 | OAuth sign-in buttons + callback handler                 | `client.getAvailableOAuthProviders()`                                                                                                                        | ✅          |
-| Account area (profile + order history)                   | `client.getMyProfile()`, `client.getMyOrders()`                                                                                                              | ✅          |
+| Account area (profile + order history)                   | `client.getMyProfile()`, `client.updateMyProfile()`, `client.getMyOrders()`                                                                                  | ✅          |
 | Loyalty & rewards (points balance + tiers + redeem)      | `client.getLoyaltyStatus()`, `client.getAvailableRewards()`, `client.getRecommendedReward()`, `client.redeemLoyaltyReward(id)`, `client.reportSocialShare()` | conditional |
 | Loyalty paid membership (premium subscription)           | `client.getMembershipPlans()`, `client.getMySavedPaymentMethods()`, `client.subscribeToMembership(params)`, `client.cancelMembership()`                      | conditional |
 | Embeddable loyalty widget (points + rewards on ANY site) | `client.getLoyaltyWidgetSession()`                                                                                                                           | conditional |
 | Global header: cart count + search autocomplete          | `client.getCart()`, `client.getSearchSuggestions(query)`                                                                                                     | ✅          |
 | Discount banners + product badges                        | `client.getDiscountBanners()`, `client.getProductDiscountBadge(productId)`                                                                                   | ✅          |
 | Product reviews on PDP + JSON-LD aggregateRating         | `client.listProductReviews(id)`, `client.submitProductReview(id, …)`                                                                                         | ✅          |
+| Customer photos on reviews                               | `client.uploadReviewPhoto(productId, file)`, then `imageKeys` on submit                                                                                      | conditional |
 | Site chrome (header + footer + announcement bar)         | `client.content.header.get()`, `client.content.footer.get()`, `client.content.announcement.list()`                                                           | ✅          |
 | FAQ page                                                 | `client.content.faq.get('main', locale)`                                                                                                                     | conditional |
 | Static pages catch-all (`/pages/[slug]`)                 | `client.content.page.getBySlug(slug, locale)`                                                                                                                | conditional |
@@ -98,6 +99,7 @@ Violating any of these causes production incidents or broken orders. Read them b
 
 - ALWAYS handle the `requiresVerification` flag in `registerCustomer` and `loginCustomer` responses. If true, route to the verify-email step BEFORE treating the user as logged in.
 - ALWAYS build the verify-email, forgot-password, and reset-password flows even when the store currently has email verification disabled. They auto-hide when unused.
+- ALWAYS read `requireBirthday` from `getStoreInfo()` before rendering the signup form. When it is true the merchant made the birthday mandatory on that sales channel, and `registerCustomer` returns HTTP 400 unless you send both `birthMonth` (1-12) and `birthDay` (1-31). Month and day only, never a year.
 - ALWAYS build OAuth button placeholders and a callback handler even when no OAuth provider is configured.
 - NEVER silently swallow auth errors. Render the specific error (invalid credentials, expired token, rate limited).
 
@@ -177,10 +179,12 @@ These sequences are non-negotiable. The order of SDK calls matters.
 
 ### Registration flow
 
-1. Collect email, password, first name, last name.
+1. Collect email, password, first name, last name. Read `requireBirthday` from `getStoreInfo()`: when it is true, collect a birthday month and day as well, because the register call is rejected without them.
 2. Call `registerCustomer`:
    ```ts
    const result = await client.registerCustomer({ email, password, firstName, lastName });
+   // Channel requires a birthday? Send both fields, never a year:
+   // { email, password, firstName, lastName, birthMonth: 4, birthDay: 17 }
    ```
 3. Branch on `result.requiresVerification`:
    - `true` → store token temporarily, route to verify-email UI (do NOT set token yet)
@@ -1907,7 +1911,8 @@ fields.forEach((field) => {
   // field.minLength, field.maxLength: validation for text fields
   // field.minValue, field.maxValue: validation for number fields
   // field.dateAvailability: constraints for DATE/DATETIME fields (blocked
-  //   weekdays/dates, min/max date, business hours + slots) — see
+  //   weekdays/dates, min/max date, leadTimeMinutes/cutoffTime/maxDaysAhead,
+  //   business hours + slots) — see
   //   computeAvailableSlots()/getBusinessHoursForDate()/isDateValueAllowed()
   //   below. DATE values are sent as "YYYY-MM-DD"; DATETIME as one ISO-8601
   //   value — never a date with a slot LABEL glued on ("...T13:00-14:00" is
@@ -2681,7 +2686,8 @@ const updatedCheckout = await client.setCheckoutCustomFields(checkoutId, {
 **DATE / DATETIME fields with availability constraints**
 
 A `DATE`/`DATETIME` field's `dateAvailability` (blocked weekdays, blocked specific
-dates, min/max date range, and — for `DATETIME` — business hours + time
+dates, min/max date range, the relative bounds `leadTimeMinutes` / `cutoffTime` /
+`maxDaysAhead`, and — for `DATETIME` — business hours + time
 slots) is a merchant-configured restriction on which values the customer may
 pick. Use `computeAvailableSlots()` / `getBusinessHoursForDate()` /
 `isDateValueAllowed()` to drive your own date-picker/slot-picker UI — the SDK
@@ -2700,19 +2706,24 @@ const { timezone } = await client.getStoreInfo(); // IANA string, e.g. "Asia/Jer
 const deliveryField = fields.find((f) => f.key === 'delivery_slot');
 const availability = deliveryField?.dateAvailability;
 
+// The clock. Without it leadTimeMinutes/cutoffTime/maxDaysAhead are SKIPPED and
+// the picker offers days the server refuses; `now` defaults to this instant.
+const clock = { timezone };
+
 // Disable days on your calendar of choice. Note the SECOND condition: once
 // businessHours has any entry it is an ALLOWLIST, so a weekday it doesn't
 // mention is closed all day even though the calendar rules accept it.
 const isDayDisabled = (ymd: string) =>
-  !isCalendarDateAllowed(ymd, availability) ||
+  !isCalendarDateAllowed(ymd, availability, clock) ||
   (!!availability?.businessHours?.length &&
-    getBusinessHoursForDate(availability, ymd).length === 0);
+    getBusinessHoursForDate(availability, ymd, clock).length === 0);
 
 // Once the customer picks a day, offer times. computeAvailableSlots() returns
 // [] when the field has no slotDurationMinutes — that is NOT "day closed",
-// which is why the windows are checked separately.
-const slots = computeAvailableSlots(availability, '2026-08-15'); // ["09:00", "09:30", ...]
-const windows = getBusinessHoursForDate(availability, '2026-08-15'); // [{ weekday, open, close }]
+// which is why the windows are checked separately. A day with two windows
+// (mornings and evenings) yields both, in chronological order.
+const slots = computeAvailableSlots(availability, '2026-08-15', clock); // ["09:00", "09:30", ...]
+const windows = getBusinessHoursForDate(availability, '2026-08-15', clock); // [{ weekday, open, close }]
 
 if (slots.length) {
   // Render slot buttons; the submitted time must equal a slot start exactly.
@@ -2736,6 +2747,19 @@ What you read back is normalized, not the string you sent: `YYYY-MM-DD` for
 `DATE`, an ISO-8601 UTC instant for `DATETIME`. Use `parseDateFieldValue()` if
 you want to apply the exact same parse client-side before submitting.
 
+**Relative bounds.** `leadTimeMinutes` puts the earliest bookable moment at
+`now + leadTime`. `cutoffTime` ("HH:mm", store-local) pushes the earliest
+bookable DATE on by a further day once the store clock reaches it, which is how
+"order by 14:00 for tomorrow" is expressed. `maxDaysAhead` is a rolling ceiling
+counted from today. All three are re-resolved on every call, so unlike an
+absolute `minDate` they never go stale, and all three apply to plain `DATE`
+fields as well. They are accepted on **checkout** custom fields only: a product
+metafield and an order custom field are written by an admin rather than picked
+by a shopper, so there is no ordering moment to measure them from and the API
+rejects them there. `resolveRelativeBounds(availability, clock)` returns the
+concrete dates they currently mean, which is what to show a shopper who asked
+for something too soon.
+
 The backend independently re-validates every submitted value against the same
 constraints at write time — this is a client-side UX aid, not the source of
 enforcement.
@@ -3481,12 +3505,24 @@ if (intent.clientSdk?.renderType === 'sandbox') {
 > characters" produces a 400 the shopper cannot explain, and render the server's
 > message verbatim when one comes back.
 
+> **Birthday fields.** `birthMonth` (1-12) and `birthDay` (1-31) are optional,
+> month and day only, never a year. Send both or neither: one on its own is
+> rejected with HTTP 400, and so is a day the month does not have. When
+> `getStoreInfo().requireBirthday` is true the merchant made the birthday
+> mandatory on that sales channel and a register call without it fails with
+> HTTP 400. That flag only reaches sales-channel mode (`salesChannelId`); a
+> `storeId`-mode storefront never receives it and its register route never
+> enforces it.
+
 ```typescript
 const auth = await client.registerCustomer({
   email: 'customer@example.com',
   password: 'SecurePass123!',
   firstName: 'John',
   lastName: 'Doe',
+  // Optional, unless getStoreInfo().requireBirthday is true. Both or neither.
+  birthMonth: 4,
+  birthDay: 17,
 });
 
 // Check if email verification is required
@@ -3557,6 +3593,12 @@ console.log(profile.firstName);
 console.log(profile.email);
 console.log(profile.addresses);
 
+// Birthday the customer saved: month and day only, never a year. Both fields
+// arrive together or neither does, so testing one is enough.
+if (profile.birthMonth && profile.birthDay) {
+  console.log(`Birthday: ${profile.birthDay}/${profile.birthMonth}`);
+}
+
 // profile.role is a free-form segment the merchant sets from the dashboard
 // (e.g. "wholesale", "vip") — not customer-editable. Use it to gate custom
 // storefront features/UI: wholesale pricing, a VIP section, etc.
@@ -3565,6 +3607,30 @@ if (profile.role === 'wholesale') {
 }
 ```
 
+#### Update Customer Profile
+
+Storefront or vibe-coded mode, requires `customerToken`. The call returns the
+saved `CustomerProfile`, so re-render the form from the response instead of
+from what you sent. `email` and `role` are not customer-editable and are not
+accepted here.
+
+```typescript
+const updated = await client.updateMyProfile({
+  firstName: 'John',
+  lastName: 'Doe',
+  phone: '+15550100',
+  acceptsMarketing: true,
+  // Birthday: month and day only, never a year. Send both or neither, and the
+  // day has to exist in the month (day 31 in February is rejected with 400).
+  birthMonth: 4,
+  birthDay: 17,
+});
+
+// The saved birthday comes back on the response and on getMyProfile(), so the
+// profile form shows what the customer stored instead of two empty fields.
+console.log(updated.birthMonth, updated.birthDay);
+```
+
 #### Get Customer Orders
 
 ```typescript
@@ -3646,10 +3712,15 @@ await client.registerCustomer({ email, password, referralCode: refFromQuery });
 // bonus (held through the program's pending window, like order points).
 ```
 
-Birthday gifts need no SDK calls beyond profile data: set the customer's
-`birthMonth`/`birthDay` (1-12 / 1-31, no year) via `updateMyProfile()` and the
-platform emails a one-time gift coupon ahead of their birthday automatically
-(when the store has it enabled).
+Birthday gifts need no SDK calls beyond profile data: save the customer's
+`birthMonth`/`birthDay` (1-12 / 1-31, month and day only, never a year) via
+`updateMyProfile()` and the platform emails a one-time gift coupon ahead of
+their birthday automatically (when the store has it enabled). Both values come
+back on `getMyProfile()`, on `getCheckoutPrefillData()` and on the `Customer`
+read types, so a profile form renders the birthday the customer already gave
+you rather than an empty pair of fields. `registerCustomer()` accepts the same
+two fields, and a channel with `requireBirthday` turned on insists on them at
+signup.
 
 #### Paid Loyalty Membership
 
@@ -3741,6 +3812,8 @@ const auth = await client.registerCustomer({
   email: 'customer@example.com',
   password: 'SecurePass123!',
   firstName: 'John',
+  // Add birthMonth + birthDay here too when getStoreInfo().requireBirthday is
+  // true, or this call fails with HTTP 400 before any email is sent.
 });
 
 if (auth.requiresVerification) {
@@ -5146,12 +5219,17 @@ is what stops an API key from escalating its own team permissions. Pointing the
 the correct path would earn a `403` instead of a `404`. Invite, re-scope and remove
 members in the dashboard.
 
-> **The older account-level methods are not the workaround.** `getTeamMembers`,
+> **The older account-level methods are not a substitute for this.** `getTeamMembers`,
 > `getTeamInvitations`, `inviteTeamMember`, `resendTeamInvitation`, `revokeTeamInvitation`,
 > `updateTeamMemberRole` and `removeTeamMember` do still reach `/api/v1/team/…` — but they
-> manage the **account** team, not a store's, and all seven are `@deprecated`. Their JSDoc
-> tells you to migrate to the store-level methods named above; ignore that advice, because
-> those methods 404. Don't build new integrations on either family.
+> manage the **account** team, not a store's. They will not invite anyone to a store or
+> scope a member to a sales channel; only the dashboard does that.
+>
+> **For the account team, they remain the supported call.** All seven are tagged
+> `@deprecated`, which records an intent to retire them — not a migration you can perform
+> today. There is no API-key replacement: the store-level methods named above are
+> dashboard-only. Keep using these until an API-key route ships, and expect the tag to
+> outlive this note.
 
 ### Email Settings & Templates
 
@@ -6082,6 +6160,8 @@ export default function RegisterPage() {
     setLoading(true);
     setError('');
     try {
+      // Add birthMonth + birthDay to this call (both, never a year) when
+      // getStoreInfo().requireBirthday is true for the channel.
       const auth = await client.registerCustomer({ email, password, firstName, lastName });
 
       // Check if email verification is required
@@ -6183,6 +6263,9 @@ export default function AccountPage() {
           <h2 className="text-xl font-bold mb-4">Profile</h2>
           <p><strong>Name:</strong> {profile.firstName} {profile.lastName}</p>
           <p><strong>Email:</strong> {profile.email}</p>
+          {profile.birthMonth && profile.birthDay && (
+            <p><strong>Birthday:</strong> {profile.birthDay}/{profile.birthMonth}</p>
+          )}
         </div>
 
         <div className="border rounded p-6">
@@ -6304,6 +6387,89 @@ const forms = await brainerce.contactForms.list();
 
 **Rate limit:** 3 submissions per 60 seconds per IP. Include a hidden honeypot field (and do not submit it) — bots that auto-fill every input will be rejected.
 
+**A form keyed `newsletter` is still an inquiry.** The key is a label, not a behaviour: the submission files a message and never touches marketing consent, so that address can never receive a campaign. For a mailing list, use [Newsletter Signup](#newsletter-signup-marketing-opt-in).
+
+---
+
+## Newsletter Signup (marketing opt-in)
+
+**SDK >= 1.60.** The email-capture popup, the footer subscribe bar, the exit-intent modal.
+
+```typescript
+await brainerce.marketing.subscribe({
+  email: 'jane@example.com',
+  locale: 'he', // language of the confirmation email
+  source: 'popup', // free-form, for the merchant's reporting
+  honeypot: hiddenFieldValue, // must be empty
+});
+// → { ok: true }
+```
+
+Also accepts `firstName`, `lastName`, and `sourceMetadata` (referrer, UTM params, the page the popup fired on).
+
+**⛔ It does not subscribe anyone.** The contact is created and mailed a confirmation link; the address is unmailable — and invisible to every campaign audience — until the recipient clicks it. Render **"Check your email to confirm — including your spam folder"** on success, never "You're subscribed". The spam-folder half matters: a confirmation filtered there is the commonest reason a signup never converts, and the 24-hour resend cooldown means no second copy arrives. Single opt-in is not available: without the click, anyone could subscribe anyone else's address.
+
+**⛔ The response carries no information.** `{ ok: true }` is returned identically for a brand-new address, one that confirmed months ago, one inside its 24-hour resend cooldown, and one suppressed after a hard bounce — otherwise the form would become a way to test who shops at this store. Show one message for every success; there is no branch to write.
+
+**Rate limit:** 3 requests per 60 seconds per IP, plus one confirmation email per address per store per 24 hours. A submission inside that cooldown still returns `{ ok: true }` and silently sends nothing — do not treat it as a failure or retry it.
+
+**Locale:** pass it on a multi-language storefront, or the confirmation email falls back to the store's language. `he` and `en` are written; anything else gets English.
+
+**No discount code is minted.** For a "10% off your first order" popup, the merchant creates one coupon with the `customer_first_order` condition and you display that fixed code after a successful call.
+
+The contact appears at `Customers` in the dashboard immediately, with **Accepts marketing** off; it flips on at confirmation. It is an ordinary guest customer record — no password, no account — and is the same row if that person later registers or checks out.
+
+---
+
+## Back-in-Stock Alerts
+
+**SDK >= 1.61.** The "email me when this is back" button on a sold-out product.
+
+```typescript
+await brainerce.stockAlerts.subscribe({
+  email: 'jane@example.com',
+  productId: product.id,
+  variantId: selectedVariant.id, // pass on ANY product with variants
+  locale: 'he', // language of the alert email
+  honeypot: hiddenFieldValue, // must be empty
+});
+// → { ok: true }
+```
+
+**⛔ It is not a subscription.** One email, about one item, carrying a link that stops it. No customer account is created and no marketing consent is granted. Label the button **"Email me when it's back"**, never "Subscribe" — and because it grants no consent, never hide it from a shopper who unsubscribed from your marketing.
+
+**⛔ Render it only when `getStoreInfo().stockAlertsEnabled !== false`, the item is out of stock, AND it cannot be backordered.** Requests for anything else — a storefront whose merchant switched the feature off, an in-stock item, a backorderable one, an untracked one, an unknown product id — are silently ignored, so a button in the wrong place looks like it worked and does nothing.
+
+```typescript
+const store = await brainerce.getStoreInfo();
+// `inv` is the SELECTED VARIANT's inventory when there is one, else the product's.
+const inv = selectedVariant?.inventory ?? product.inventory;
+
+const canOfferStockAlert =
+  store.stockAlertsEnabled !== false &&
+  inv?.trackingMode === 'TRACKED' &&
+  !inv.canPurchase &&
+  (inv.backorderMode ?? 'NONE') === 'NONE';
+```
+
+`backorderMode` is on `InventoryInfo` from SDK 1.61; older backends omit it, so treat `undefined` as `'NONE'`.
+
+The merchant controls the switch — and how many people are emailed per unit restocked — under **Channel settings → Inventory**, alongside the low-stock warning.
+
+**⛔ Pass `variantId` on every variable product.** Without it the alert waits on the product as a whole, so a shopper who wanted the medium is mailed when the small returns and arrives to find their size still gone.
+
+**⛔ The response carries no information.** `{ ok: true }` is returned identically for a new request, a duplicate, an unknown product, an item already in stock, and an address suppressed after a hard bounce — otherwise the button would become a way to read the store's stock levels. Show one message for every success; there is no branch to write.
+
+**Sending is not immediate, and not to everyone.** Availability is `total - reserved`, so an expiring cart briefly lifts a sold-out item above zero; the alert waits for stock to hold for a few minutes, then goes out in waves sized to the units that came back (500 waiting and 3 units restocked is roughly 9 emails, oldest request first). A shopper can therefore sit through a restock without hearing, so never promise "you'll be the first to know".
+
+**Rate limit:** 5 requests per 60 seconds per IP, at most 25 open alerts per address per store, and a 90-day life on an unfired alert. A duplicate request is a no-op, not a second alert; once an alert has fired the person can ask again the next time that item sells out.
+
+**Locale:** pass it on a multi-language storefront, or the alert falls back to the store's language. `he` and `en` are written; anything else gets English.
+
+**What it does not do:** no SMS or WhatsApp, no price-drop alerts, and no merchant-editable template — the body is fixed so it can never start carrying a discount code, which would turn a transactional message into a marketing one needing an unsubscribe link it does not have.
+
+The merchant reads the demand at `Products → Back-in-Stock Waitlist`: products ranked by how many people are waiting, with the addresses behind each number. There is no way to mail those people anything else from there, by design.
+
 ---
 
 ## Storefront Bot (AI chat widget)
@@ -6383,16 +6549,62 @@ export async function POST(req: Request) {
 
 ### Webhook Events
 
-| Event                | Description                     |
-| -------------------- | ------------------------------- |
-| `product.created`    | New product created             |
-| `product.updated`    | Product details changed         |
-| `product.deleted`    | Product removed                 |
-| `inventory.updated`  | Stock levels changed            |
-| `order.created`      | New order received              |
-| `order.updated`      | Order status changed            |
-| `cart.abandoned`     | Cart abandoned (no activity)    |
-| `checkout.completed` | Checkout completed successfully |
+**These 21 event types are what a subscription can actually register.** The
+backend validates the `events` array on create against exactly this list, so
+anything outside it is rejected rather than silently accepted.
+
+| Event                 | Description                                                                                                                                                                                              |
+| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `order.created`       | New order placed (any payment status)                                                                                                                                                                    |
+| `order.updated`       | Order metadata changed (status, address, items)                                                                                                                                                          |
+| `order.paid`          | Order is paid — provider capture **or** a merchant-recorded out-of-band payment (cash on delivery, bank transfer). Never assume a provider was involved; `payment.succeeded` does **not** fire for these |
+| `order.fulfilled`     | All items marked shipped/delivered                                                                                                                                                                       |
+| `order.cancelled`     | Order cancelled (by merchant or customer)                                                                                                                                                                |
+| `order.refunded`      | Order fully or partially refunded                                                                                                                                                                        |
+| `customer.created`    | New customer account created                                                                                                                                                                             |
+| `customer.updated`    | Customer profile or contact details changed                                                                                                                                                              |
+| `customer.deleted`    | Customer account deleted                                                                                                                                                                                 |
+| `product.created`     | New product added to catalog                                                                                                                                                                             |
+| `product.updated`     | Product attributes, variants, or pricing changed                                                                                                                                                         |
+| `product.deleted`     | Product removed from catalog                                                                                                                                                                             |
+| `inventory.updated`   | Stock level changed (any reason)                                                                                                                                                                         |
+| `inventory.low`       | Stock fell below the low-stock threshold                                                                                                                                                                 |
+| `checkout.completed`  | Checkout completed (synonym of `order.created` for now)                                                                                                                                                  |
+| `checkout.abandoned`  | Cart inactive for 1+ hours with no completion                                                                                                                                                            |
+| `payment.succeeded`   | Payment provider confirmed funds captured                                                                                                                                                                |
+| `payment.failed`      | Payment provider rejected the transaction                                                                                                                                                                |
+| `payment.refunded`    | Refund posted to the customer                                                                                                                                                                            |
+| `blog.post.published` | Post went live (manual, scheduled, or SEO Autopilot)                                                                                                                                                     |
+| `blog.post.updated`   | Published post content changed                                                                                                                                                                           |
+
+Payload shapes for each are in the
+[Event Catalogue](https://brainerce.com/docs/webhooks/events).
+
+`customer.created` now fires for **shopper self-signup on your storefront**, not
+just merchant-created customers, so a storefront that registers customers will
+start seeing it.
+
+> **⚠️ The `WebhookEventType` type does not match this table yet — in both
+> directions.** Treat the table, not the type, as the truth about what you can
+> subscribe to.
+>
+> **14 subscribable events are missing from the type:** `order.paid`,
+> `order.fulfilled`, `order.cancelled`, `order.refunded`, `customer.created`,
+> `customer.updated`, `customer.deleted`, `inventory.low`, `checkout.abandoned`,
+> `payment.succeeded`, `payment.failed`, `payment.refunded`,
+> `blog.post.published`, `blog.post.updated`. So
+> `isWebhookEventType(event, 'customer.created')` and a
+> `createWebhookHandler({ 'order.paid': … })` key **fail to compile**, even
+> though both deliver correctly at runtime. Cast the name
+> (`'customer.created' as WebhookEventType`) or read `event.event` as a
+> `string` and switch on it yourself. Do not conclude the event does not exist.
+>
+> **8 names in the type cannot be subscribed to at all:** `coupon.created`,
+> `coupon.updated`, `coupon.deleted`, `cart.created`, `cart.updated`,
+> `cart.abandoned`, `checkout.started`, `checkout.failed`. These compile
+> cleanly and then fail at subscription time. `cart.abandoned` in particular
+> was listed as a supported event here for a long time — use
+> `checkout.abandoned` instead.
 
 ---