DB migration compat / Back-compat — Current branch migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code (push) Has been cancelled
DB migration compat / Forward-compat — Current branch code with ${{ needs.check-migrations-changed.outputs.base_branch }} branch migrations (push) Has been cancelled
### Context
We didn't have an easy place for a user to see their domain statistics
and track their sent emails, either overall or by draft. Additionally,
there was scope creep with the sidebar, where we were supporting more
pages. Our emails landing page was also rather confusing, especially
toggling/ working with different email server types. So, we decide to
add a "sent" page, to track email logs and email statistics, as well as
let users temporarily override their sending limits if need be.
Additionally, a user may want to see a particular email in more detail:
what stage is it in? How did it proceed through time? How can I pause
the sending of this email or change the scheduled time or edit the code?
We allow for that to happen.
### Summary of Changes
#### New Pages
1. **Sent Page:** A Domain Reputation card lets you track how many of
your sent emails were bounced or marked as spam as well as how much
capacity you have left. We also provide a temporary override, where you
can use up to 4 times your capacity for a limited period of time.
Additionally, we provide an email log that lets you see the recently
sent emails. You can also toggle this view from a "list all emails" to
"group by template/draft" which shows stats for each template/draft id
(i.e a bar showing how many emails were sent, are pending, were marked
as spam, were bounced etc, and the total number of emails sent with that
template or draft). Clicking on an email in the list all view takes you
to the "email-viewer" endpoint for that email (see below). Clicking on a
template/draft in the group by view takes you to a page where you can
see the statistics for that template/draft in more detail (the "send"
stage view for that template/draft, as referenced below).
2. **Settings Page:** This is a new page we created because the old
"emails" landing page wasn't doing its job. This page is to track all
the email settings. Currently, we put in 2 sections. A "theme settings"
card where users can see their active theme and click on a button to be
navigated to the themes page. This is necessary as we remove themes from
the sidebar. The other section is a card for email server and domain
configuration - you can change your server type and adjust the settings
or send a test email. It's cleaner and less noisy.
3. **Drafts Page**: There are a lot of changes here. On the landing
page, we actually separate out the drafts into "active drafts" and
"draft history" because drafts are meant to be fire-and-forget, not
reusable. We also add the functionality to create a draft from a
template. This was tricky to manage because templates rely on template
variables which sent to the backend along with the code and injected
during render time. We deal with this by having AI rewrite the template
source code to remove any references to template variables and to make
the draft standalone. The drafts page has been separated into a
stepper-controlled multi stage process:
draft->recipients->schedule->sent. Sent is a read only view that shows
you the statistics of the emails sent using that draft, as mentioned
earlier. You can also see the sent view of a historical draft. You can
also bulk pause/cancel any unsent emails from the sent view of the
drafts.
4. **Sidebar Updates**: The email sidebar now doesn't show "themes" or
"emails" (the old landing page), but it does show "settings" and "sent",
and the default landing page for emails is "sent".
5. **Email Viewer**: When you click on an individual email, you get
navigated here. This has a timeline showing the progress of the email on
the right, and some optional info for the user that's toggleable on the
right bottom, while having either a preview of the email if it's sent or
a way to edit it. You can also change the scheduledAt date of an email
if it hasn't already been sent.
#### Bug Fixes
1. **Search in `TeamMemberSearchTable`**: This was broken. Every time
you tried to enter or remove a character, it would trigger skeleton
loading that overlapped the search bar too, preventing you from
adding/removing more. This was caused because the `useUser` hook
eventually ended up calling a `use` hook, which throws a promise that
triggers a suspense. This, coupled with the fact that the implementation
of `TeamMemberSearchTable` involved a prop-drilling/ dependency
inversion approach to passing down its toolbar to a base table
component, meant the suspense would cover the toolbar too and couldn't
be scoped to just the table. A refactor has gotten rid of the need for
those base components while fixing tables in `payments/customers`,
`teams/team_id`, and `payments/transactions` on top of the existing use
in email drafts recipients stage. We also dedupped some code.
2. **Stale draft fetches on draft landing page**: `useEmailDrafts` uses
an asyncCache to cache the fetched drafts. It is used on the drafts
landing page to render the drafts. When a draft is sent, its `sentAt` is
marked versus when it is still active, it is marked as null. The cache
was stale and so navigating to the landing page after firing off a draft
would errorneously represent that draft as still active and indeed, even
allow you to edit it and fire it again. This violated the principle of
drafts being fire and forget. This has been dealt with by adding
functionality to refresh the draft cache upon firing off a draft.
#### Other Changes
1. We bumped up the base time for the exponential send attempt retry
backoff in `email-queue-step` to 20 seconds. The previous base was two
seconds, and this effectively just made it wait until the next iteration
of the `email-queue-step` cron job or at most an iteration that wasn't
too far away. When an outage with our provider happens, it may take a
while for it to be resolved, so a longer backoff is justified
2. We transitioned the themes page and the templates page to using the
new components, though deeper UI refactors for them were out of scope
for this ticket.
3. We implement a "temporarily increase capacity" button, that bumps up
the throughput/ capacity limit fourfold for a user for a given period of
time. It works like this:
> Clicking the button sets a boost expiredat time.
> When this time is set and still valid, the capacity rate is multiplied
by 4.
> When the button is clicked, trigger a loading spinner until the route
finishes processing.
> When the timer runs out, we reset the button back to its original
state.
> We dont need to wrap the onclick with runAsyncWithAlert because the
component does that already.
4. We add a new default theme: a colorful theme with a lavender base.
This was mainly done so we could have three times in a theme showcase in
the settings page.
### UI Demos
**Sent Page Demo:**
https://github.com/user-attachments/assets/19294a90-bb65-4f00-9a97-111f6c08287f
**Drafts Page Demo**
https://github.com/user-attachments/assets/847609ef-d699-470c-a699-297bb9e17f04
**Settings Page Demo**
https://github.com/user-attachments/assets/190a3829-036a-4f57-89c0-a873bef5a7ce
**Email Viewer Page Demo**
https://github.com/user-attachments/assets/3bc50159-4acb-4865-a4dd-830c84ee4235
---------
Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>
<!--
Make sure you've read the CONTRIBUTING.md guidelines:
https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Provision local-emulator projects from a local config file and return
emulator credentials via a new internal endpoint.
* Dashboard: "Open config file" flow to open local projects and refresh
owned projects.
* **Changes**
* Branch config can prefer/read/write local files for emulator projects.
* Environment config updates/resets are blocked for local-emulator
projects.
* Dashboard UI shows read-only notices and disables project creation in
emulator mode.
* Added DB mapping and a standard env flag to identify local-emulator
projects.
* **Tests**
* New E2E tests covering provisioning and config restrictions.
* **Chores**
* Removed legacy emulator docs and compose; added CI workflow for
local-emulator E2E runs.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>
### Summary of Changes
Just bumped up polling, removed unnecessary wait checks in tests that
don't need them. Minor changes, not an exhaustive list of flaky test
fixes
Note that importing a function into a file B that was exported from a
test file A causes vitest to see all the tests in test file A as being
under file B. This messes up CI and makes it harder to track failing
tests.
<!--
Make sure you've read the CONTRIBUTING.md guidelines:
https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Upgraded build system configuration to integrate new build tooling.
* Added new build dependency to support enhanced build and deployment
capabilities.
* Updated repository ignore patterns to exclude additional
build-generated artifacts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>
<!--
Make sure you've read the CONTRIBUTING.md guidelines:
https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Full Playground with multi-component live previews and generated TSX
snippets.
* New reusable Design data table and richer editable-grid interfaces.
* **Refactor**
* Replaced legacy UI primitives across many pages with unified Design
components (cards, buttons, alerts, badges, tabs).
* **Improvements**
* PageLayout supports optional content overflow.
* Enhanced inline editing, copy-to-clipboard, async toggles with
confirmation dialogs, dialog/form default value handling, and consistent
alerts/UX.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>
Co-authored-by: nams1570 <amanganapathy@gmail.com>
<!--
Make sure you've read the CONTRIBUTING.md guidelines:
https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a new "Hosted Components" app with its own app shell, routing,
auth-aware UI, a handler route, and a welcome page showing the signed-in
user.
* **Chores**
* Added dev tooling and configuration for the new app (build, lint,
typecheck, Vite/TS, package manifest) and updated dev env API URL.
* **Tests**
* Excluded the new app from the test workspace.
* **Bug Fixes**
* Suppressed noisy console errors for a specific internal sentinel and
clarified related error messaging.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>
DB migration compat / Back-compat — Current branch migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code (push) Has been cancelled
DB migration compat / Forward-compat — Current branch code with ${{ needs.check-migrations-changed.outputs.base_branch }} branch migrations (push) Has been cancelled
<!--
Make sure you've read the CONTRIBUTING.md guidelines:
https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Managed email domain onboarding: setup, DNS provisioning,
verification, status checks, and apply flow (Resend-backed).
* **UI**
* Project email settings: managed-provider setup dialog, managed sender
fields, status display, and test-send mapping.
* **Integrations**
* DNS provider automation and Resend webhook handling for domain status
updates; scoped keys for sending.
* **API**
* Admin endpoints / client APIs to setup, check, list, and apply managed
email domains.
* **Tests**
* End-to-end tests covering the full onboarding flow.
* **Chores**
* Added environment variables and config schema support for Resend and
DNS integrations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Added Stack CLI with authentication (login/logout) commands.
* Added project management commands to list and create projects.
* Added configuration management to pull and push project settings.
* Added code execution capability to run JavaScript expressions.
* Added initialization command for Stack Auth setup.
* **Tests**
* Added comprehensive end-to-end test suite for CLI functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
DB migration compat / Back-compat — Current branch migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code (push) Has been cancelled
DB migration compat / Forward-compat — Current branch code with ${{ needs.check-migrations-changed.outputs.base_branch }} branch migrations (push) Has been cancelled
DB migration compat / Back-compat — Current branch migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code (push) Has been cancelled
DB migration compat / Forward-compat — Current branch code with ${{ needs.check-migrations-changed.outputs.base_branch }} branch migrations (push) Has been cancelled
DB migration compat / Back-compat — Current branch migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code (push) Has been cancelled
DB migration compat / Forward-compat — Current branch code with ${{ needs.check-migrations-changed.outputs.base_branch }} branch migrations (push) Has been cancelled
<!--
Make sure you've read the CONTRIBUTING.md guidelines:
https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **API Changes**
* Session replay batch upload endpoint now enforces a maximum payload
size of 1MB, reduced from 5MB. Requests exceeding the new limit will
receive a payload-too-large error response.
* **Tests**
* Updated batch upload tests to validate behavior under the new 1MB
maximum payload size constraint.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
[Open this suggestion in Promptless to view citations and reasoning
process](https://app.gopromptless.ai/change-history/e6033b34-4005-4a9e-9d21-d809e2d57896)
Adds documentation for the two new built-in email templates:
`payment_receipt` (sent when payments succeed) and `payment_failed`
(sent when payments fail). Updates the Emails guide to list these new
templates alongside existing authentication templates, and adds a
"Payment Emails" section to the Payments guide explaining that these
notifications are sent automatically for both one-time purchases and
subscription renewals.
### Trigger Events
<details>
<summary><a
href="https://github.com/stack-auth/stack-auth/pull/1106">stack-auth/stack-auth
PR #1106: payment email templates</a></summary>
<br>
**Promptless Research** (1 GitHub PR)
- [Reviewed
stack-auth/stack-auth#1106](https://github.com/stack-auth/stack-auth/pull/1106)
**Agent Response**
> I've completed the documentation updates for PR #1106. Here's a
summary of the changes:
>
> ## Documentation Suggestion Created
>
> **Title:** Document payment email templates
>
> **Changes made:**
>
> 1. **Emails guide** (`docs/content/docs/(guides)/apps/emails.mdx`):
> - Added `payment_receipt` and `payment_failed` to the "Built-in Email
Templates" section, keeping them consistent with the existing format for
other templates
>
> 2. **Payments guide**
(`docs/content/docs/(guides)/apps/payments.mdx`):
> - Added a new "Payment Emails" subsection under Dashboard Management
explaining that Stack Auth automatically sends email notifications when
payments are processed
> - Documents both templates with their key details (receipt link,
failure reason, etc.)
> - Notes that these apply to both one-time purchases and subscription
renewals
> - Includes a pointer to where templates can be customized
>
> The suggestion is ready for review at:
https://app.gopromptless.ai/change-history/e6033b34-4005-4a9e-9d21-d809e2d57896
</details>
---
**Help us improve Promptless** — If this suggestion missed the mark,
please [share quick
feedback](https://app.gopromptless.ai/change-history/e6033b34-4005-4a9e-9d21-d809e2d57896?openFeedback=1).
*If you want Promptless to make further changes on this PR, feel free to
leave a comment tagging Promptless (It won't show up in the user drop
down but Promptless will get it!)*
Co-authored-by: promptless[bot] <179508745+promptless[bot]@users.noreply.github.com>
Co-authored-by: Madison <madison.w.kennedy@gmail.com>
[Open this suggestion in Promptless to view citations and reasoning
process](https://app.gopromptless.ai/change-history/ea7c7471-778d-42ea-9845-fa380f013560)
Documents the new `is_restricted` and `restricted_reason` JWT claims
introduced for the onboarding/restricted users feature. Updates the JWT
documentation to explain these fields in the claims section, adds them
to the example payload, documents the restricted user token structure,
and adds the `include_restricted` JWKS parameter for manual token
verification.
### Trigger Events
<details>
<summary><a
href="e400985754...de0f937f46">stack-auth/stack-auth
commit (dev): de0f937 [CHANGELOG] - 2026.01.21</a></summary>
<br>
**Promptless Research** (1 webpage, 1 GitHub PR)
- [Read webpage from
github.com](e400985754...de0f937f46)
- [Reviewed
stack-auth/stack-auth#1069](https://github.com/stack-auth/stack-auth/pull/1069)
**Agent Response**
> I've completed my analysis of the changelog entry and created the
necessary documentation update.
>
> ## Summary
>
> After reviewing the changelog entry for **2026.01.21**, I identified:
>
> ### Already Covered by Existing Suggestions
> The payment-related items were already documented by existing
suggestions:
> - **Payments Settings page** → covered by the "Document payment
settings" suggestion
> - **Subscription renewal emails** → covered by the "Document payment
email templates" suggestion
> - **Invoice visibility** → covered by the "Document invoice listing
feature" suggestion
>
> ### New Documentation Created
> I created a new suggestion to address the remaining item: **"Updated
JWT documentation to include `isRestricted` and `restrictedReason`"**
>
> The suggestion updates the JWT Tokens documentation with:
> - **New claims documentation**: Added `is_restricted` (boolean) and
`restricted_reason` (nullable object with `type` field) to the Stack
Auth Specific Claims section
> - **Updated example payload**: Added the new fields to the example JWT
payload
> - **Restricted user tokens**: Documented how restricted user tokens
differ (`:restricted` audience suffix)
> - **JWKS parameter**: Added documentation for the
`include_restricted=true` parameter in the Manual JWT Verification
section
>
> These fields were introduced in PR #1069 "Onboarding app & restricted
users" to support the new onboarding flow where users who haven't
completed requirements (like email verification) are marked as
"restricted."
</details>
---
**Help us improve Promptless** — If this suggestion missed the mark,
please [share quick
feedback](https://app.gopromptless.ai/change-history/ea7c7471-778d-42ea-9845-fa380f013560?openFeedback=1).
*If you want Promptless to make further changes on this PR, feel free to
leave a comment tagging Promptless (It won't show up in the user drop
down but Promptless will get it!)*
---------
Co-authored-by: promptless[bot] <179508745+promptless[bot]@users.noreply.github.com>
Co-authored-by: Madison <madison.w.kennedy@gmail.com>
[Open this suggestion in Promptless to view citations and reasoning
process](https://app.gopromptless.ai/suggestions/9355c2e9-3f8e-4b9e-8857-92e937f4b7df)
Adds the required `lastModified` field to the sign-up-rules.mdx
frontmatter. Per client documentation requirements, all new MDX
documents must include a `lastModified` field in the frontmatter with
the current date.
### Trigger Events
<details>
<summary><a
href="e9886bc45a...4af15344eb">stack-auth/stack-auth
commit (dev): 4af1534 docs: Document Sign-up Rules feature
(#1183)</a></summary>
<br>
**Promptless Research** (1 GitHub PR)
- [Reviewed
stack-auth/stack-auth#1183](https://github.com/stack-auth/stack-auth/pull/1183)
**Agent Response**
> I've completed my analysis of this commit and created a suggestion to
fix an issue I found.
>
> ## Summary
>
> **Trigger:** Commit `4af1534` merged PR #1183 which documented the
Sign-up Rules feature.
>
> **What I found:** The new `sign-up-rules.mdx` file was missing the
required `lastModified` field in its frontmatter. Per documentation
requirements, all new MDX documents must include this field with the
current date.
>
> **Fix created:** I created a
[suggestion](https://app.gopromptless.ai/suggestions/9355c2e9-3f8e-4b9e-8857-92e937f4b7df)
that adds the missing `lastModified: "2026-02-24"` field to the
sign-up-rules.mdx frontmatter.
>
> The underlying Sign-up Rules documentation content itself is
comprehensive and well-written, covering rule creation, conditions,
actions, priority/default settings, common use cases, analytics, and the
rule testing feature.
</details>
---
_Tip: Set up a GitHub Issues trigger in
[Projects](https://app.gopromptless.ai/projects) to enable @Promptless
mentions in issues 🐙_
Co-authored-by: promptless[bot] <179508745+promptless[bot]@users.noreply.github.com>
Co-authored-by: Madison <madison.w.kennedy@gmail.com>
[Open this suggestion in Promptless to view citations and reasoning
process](https://app.gopromptless.ai/change-history/f3f4cc12-c710-4d2d-96cd-e5443c52c8f1)
Updates the Email Configuration documentation to mention that port 2465
is now supported alongside port 465 for implicit TLS (SMTPS)
connections. Also clarifies the terminology: 587 uses STARTTLS while
465/2465 use implicit TLS from byte 1.
### Trigger Events
<details>
<summary><a
href="02c67ef532...2288c9c65c">stack-auth/stack-auth
commit (dev): 2288c9c Port 2465 should have implicit TLS from byte
1</a></summary>
<br>
**Promptless Research** (1 webpage)
- [Read webpage from
github.com](02c67ef532...2288c9c65c)
**Agent Response**
> I've completed my analysis and created a documentation suggestion for
this commit.
>
> ## Summary
>
> The commit `2288c9c` adds port 2465 as a supported implicit TLS
(SMTPS) port alongside the existing port 465. This is a small but
meaningful fix for users who use non-standard SMTP ports.
>
> ## Documentation Change
>
> I created a suggestion that updates the **Email Configuration**
section in the Emails guide:
>
> **Before:**
> > Port: SMTP port (typically 587 for TLS or 465 for SSL)
>
> **After:**
> > Port: SMTP port (typically 587 for STARTTLS, or 465/2465 for
implicit TLS)
>
> This change:
> 1. Documents the newly supported port 2465 for implicit TLS
connections
> 2. Clarifies the terminology (STARTTLS vs implicit TLS) to be more
technically precise
>
> The suggestion is available for review at:
https://app.gopromptless.ai/change-history/f3f4cc12-c710-4d2d-96cd-e5443c52c8f1
</details>
---
_Tip: Add or adjust Promptless's style guide in [Agent Knowledge
Base](https://app.gopromptless.ai/configure/settings) ✍️_
Co-authored-by: promptless[bot] <179508745+promptless[bot]@users.noreply.github.com>
Co-authored-by: Madison <madison.w.kennedy@gmail.com>
[Open this suggestion in Promptless to view citations and reasoning
process](https://app.gopromptless.ai/change-history/ec26b3ff-78d8-4ae0-818b-2ad8b29f9f85)
Adds documentation for the new partial refund feature in the Payments
dashboard. Documents that USD transactions support both full and partial
refunds (specifying an amount up to the original charge), while non-USD
transactions only support full refunds. Also clarifies refund
eligibility requirements (non-test mode purchases with associated
prices).
### Trigger Events
<details>
<summary><a
href="https://github.com/stack-auth/stack-auth/pull/1123">stack-auth/stack-auth
PR #1123: Partial refunds frontend</a></summary>
<br>
**Promptless Research** (1 GitHub PR)
- [Reviewed
stack-auth/stack-auth#1123](https://github.com/stack-auth/stack-auth/pull/1123)
**Agent Response**
> I've completed the documentation update for this PR.
>
> ## Summary
>
> I reviewed PR #1123 which adds partial refund functionality to the
payments system, allowing admins to specify custom USD refund amounts
instead of being limited to full refunds.
>
> ### Documentation Update Created
>
> I updated the **Payments** guide
(`docs/content/docs/(guides)/apps/payments.mdx`) to document this new
feature:
>
> - Added a new **"Issuing Refunds"** subsection under the Transactions
section
> - Documented that USD transactions support both full and partial
refunds (specifying an amount up to the original charge)
> - Noted that non-USD transactions only support full refunds
> - Clarified refund eligibility requirements (non-test mode purchases
with associated prices)
>
> **Suggestion URL**:
https://app.gopromptless.ai/change-history/ec26b3ff-78d8-4ae0-818b-2ad8b29f9f85
</details>
This PR ties with #1123
---
**Help us improve Promptless** — If this suggestion missed the mark,
please [share quick
feedback](https://app.gopromptless.ai/change-history/ec26b3ff-78d8-4ae0-818b-2ad8b29f9f85?openFeedback=1).
*If you want Promptless to make further changes on this PR, feel free to
leave a comment tagging Promptless (It won't show up in the user drop
down but Promptless will get it!)*
Co-authored-by: promptless[bot] <179508745+promptless[bot]@users.noreply.github.com>
Co-authored-by: Madison <madison.w.kennedy@gmail.com>
[Open this suggestion in Promptless to view citations and reasoning
process](https://app.gopromptless.ai/change-history/09aa88eb-2871-4b0b-9014-bf08503ee645)
Adds new documentation for the Sign-up Rules feature that allows admins
to control who can sign up for their application. Documents how to
create rules in the dashboard, the available context variables (email,
emailDomain, authMethod, oauthProvider), the available actions (allow,
reject, restrict, log), rule priority ordering, default action settings,
common use cases like blocking disposable emails or restricting to
corporate domains, and how to use the built-in rule tester to simulate
sign-up requests before deploying rules. Placed under the Concepts
section.
### Trigger Events
<details>
<summary><a
href="13cd1f0f2b...7a35751f8e">stack-auth/stack-auth
commit (dev): 7a35751 Sign up rules (#1138)</a></summary>
<br>
**Promptless Research** (1 GitHub PR)
- [Reviewed
stack-auth/stack-auth#1138](https://github.com/stack-auth/stack-auth/pull/1138)
**Agent Response**
> I've completed the documentation for the Sign-up Rules feature
introduced in PR #1138.
>
> ## Summary
>
> Created a new documentation page for **Sign-up Rules** that covers:
>
> - **Overview**: How rules let admins control who can sign up using
conditions and actions
> - **Creating Rules**: Step-by-step instructions for the dashboard UI
> - **Available Conditions**: Documented all context variables (`email`,
`emailDomain`, `authMethod`, `oauthProvider`) and supported operations
(`contains`, `startsWith`, `endsWith`, `matches`, `==`, `!=`)
> - **Actions**: Explained all four action types:
> - **Allow** - Let users sign up normally
> - **Reject** - Block sign-up with optional internal logging message
> - **Restrict** - Allow sign-up but mark user for admin review (links
to JWT docs for restricted user tokens)
> - **Log** - Track patterns without affecting sign-up
> - **Priority & Default Action**: How rule ordering works and when to
use reject-by-default
> - **Common Use Cases**: Practical examples like blocking disposable
emails, corporate-only domains, and different rules per auth method
> - **Analytics**: Brief mention of the dashboard analytics showing rule
triggers
>
> The new page has been added to the navigation under the "Apps"
section, positioned near other authentication-related documentation.
</details>
<details>
<summary><a
href="457ff2bdbe...6fcf1a888f">stack-auth/stack-auth
commit (dev): 6fcf1a8 Test sign-up rules widget</a></summary>
<br>
**Promptless Research** (1 webpage)
- [Read webpage from
github.com](457ff2bdbe...6fcf1a888f)
**Agent Response**
> I've completed the documentation update for this commit. Here's a
summary:
>
> ## Summary
>
> I updated the existing [Sign-up Rules documentation
suggestion](https://app.gopromptless.ai/change-history/09aa88eb-2871-4b0b-9014-bf08503ee645)
to document the new **Test Rules widget** introduced in commit 6fcf1a8.
>
> ### Changes Made
>
> Added a new **"Testing rules"** section to the sign-up rules
documentation that covers:
>
> - **How to access the tester**: Navigate to the Sign-up Rules page and
click "Open tester"
> - **Test inputs**: Email address, authentication method (Password,
OTP, OAuth, Passkey), and OAuth provider
> - **Understanding results**:
> - **Outcome** - Whether the sign-up would be allowed or rejected, and
why
> - **Triggered rules** - All rules that matched, with their conditions
and actions
> - **Evaluation trace** - Detailed view of how every rule was evaluated
> - **Normalized context** - How the input was parsed (useful for
debugging conditions)
>
> This addition complements the existing sign-up rules documentation and
helps users test their rule configurations before deploying them to
production.
</details>
---
_Tip: Planning a big docs refactor? Use [Deep
Analysis](https://app.gopromptless.ai/deep-analysis) to get help with
the heavy lifting 🔍_
---------
Co-authored-by: promptless[bot] <179508745+promptless[bot]@users.noreply.github.com>
Co-authored-by: Madison <madison.w.kennedy@gmail.com>
### Context
We're looking at implementing plan pricing. While doing so, we
encountered a problem with Stripe.
**Problem:** when we run a stripe operation (purchase), the product info
is encoded as part of the stripe metadata request. Stripe encodes
metadata as key-value pairs, and the [value has a limit of 500
chars](https://docs.stripe.com/metadata#data). We do this because once
we run the stripe operation, stripe fires a webhook event which is
caught by our stripe webhook handler syncStripeSubscriptions. This gets
the stripe metadata info from the event and then updates our db in
prisma.
### Summary of Changes
We add a `ProductVersion` table and only pass the `productVersionId` via
stripe metadata instead of the whole product json. This
`productVersionId` is created by hashing the `productJson`. Since the
same product may be ordered differently without being intrinsically
different, we add a helper function for ensuring a canonical order to
the json. We also pass tenancy id and product id to the table.
Since there are existing subscriptions which used to pass the
productJson via metadata, we ensure backwards compatibility.
