Skip to content

docs: Document the Serverpod Cloud email identity provider default - #707

Merged
developerjamiu merged 7 commits into
serverpod:mainfrom
marcelomendoncasoares:docs/cloud-email-idp
Aug 1, 2026
Merged

docs: Document the Serverpod Cloud email identity provider default#707
developerjamiu merged 7 commits into
serverpod:mainfrom
marcelomendoncasoares:docs/cloud-email-idp

Conversation

@marcelomendoncasoares

@marcelomendoncasoares marcelomendoncasoares commented Jul 21, 2026

Copy link
Copy Markdown
Collaborator

Summary

Newly generated projects register ServerpodCloudEmailIdpConfig, not the EmailIdpConfig the setup page described. A reader following the page saw a configuration that does not match their server.dart and had nothing explaining where the emails actually come from.

Changes

  • Rewrite "Server-side configuration" around the two delivery options, with the generated default first.
  • Document ServerpodCloudEmailIdpConfig: appDisplayName, codes logged in development and test, and email sent in staging and production.
  • Describe the best-effort delivery behavior, where failures are logged, and why registration and password-reset responses do not change when delivery fails.
  • Keep the custom provider path as EmailIdpConfigFromPasswords with the mailer example, and move the pepper into the parameter list where it now comes from.
  • Move the endpoint and migration step into its own subsection. It applies to both configurations, but was previously nested inside the custom provider branch.

Reference

Move the endpoint and migration step out of the custom provider branch,
where a reader following the Serverpod Cloud path would never see it, and
fold the parameter list back into the section it documents. Split the
dense Cloud delivery paragraphs and drop the appDisplayName length limit,
which the API already enforces.
The page read as if ServerpodCloudEmailIdpConfig pointed at a transactional
email service that any server could use. It does not: the delivery is part
of the Serverpod Cloud platform, and the key it authenticates with is
injected into the deployed instance and is not obtainable anywhere else.
Say so where a self-hosted reader would otherwise pick the wrong
configuration and find out in production.
Cut the explanation block that had grown at the top of the page and the
one under Server-side configuration. The generated configuration is now
the single path through the page, followed by the endpoint and migration
step, with the Cloud-only scope and the delivery failure behavior as
short hooks where a reader runs into them. Move the custom provider to a
variant section at the end, and leave the Cloud passwords page alone.
@marcelomendoncasoares
marcelomendoncasoares marked this pull request as ready for review July 21, 2026 21:47
@marcelomendoncasoares
marcelomendoncasoares requested a review from a team July 21, 2026 21:47
@developerjamiu developerjamiu added the documentation Improvements or additions to documentation label Jul 23, 2026
Comment thread docs/06-concepts/04-authentication/04-providers/02-email/01-setup.md Outdated
Comment thread docs/06-concepts/04-authentication/04-providers/02-email/01-setup.md Outdated
Comment thread docs/06-concepts/04-authentication/04-providers/02-email/01-setup.md Outdated
Comment thread docs/06-concepts/04-authentication/04-providers/02-email/01-setup.md Outdated
@developerjamiu
developerjamiu merged commit aff2e6a into serverpod:main Aug 1, 2026
4 checks passed
@marcelomendoncasoares
marcelomendoncasoares deleted the docs/cloud-email-idp branch August 1, 2026 11:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants