Social login options
The pinned API catalogue defines Social Login Options under pro_advanced_login. Fixed Dashboard source can render returned Pro categories for level 0 when plan state requests the Pro tree; this does not prove runtime availability or provider enablement.
Source-defined category and provider boundary
The Dashboard uses a generic configuration renderer, so provider choices, fields, defaults, and controls are defined by the project’s runtime category response. Do not assume that Facebook, Google, Apple, or another provider is enabled merely because it exists in another project or historical source.
The pinned API catalogue defines Facebook, Google, and Apple child categories beneath pro_advanced_login, plus an Other Login Options child. Their enablement and returned records remain runtime state. Provider settings can include enable flags, identifiers, domains, keys, and protected secrets; the user-authentication API has separate provider verification and outbound-call paths.
Do not expose client IDs, app IDs, client secrets, private keys, redirect URLs, callback URLs, tokens, or provider-console details. Do not start OAuth or test live customer sign-in while reviewing this page.
Source-defined write and OAuth boundary
The generic settings renderer stages edits and saves changed configs sequentially, so a later failure can follow earlier accepted updates. Accepted API updates can add audit logs and run plugin hooks. These config mechanics do not prove provider readiness or a successful sign-in, and no config, credential, OAuth, provider, customer, or login action ran here.
Route level, read-only state, plan state, returned parent/child categories, dependency fields, and provider-specific configs are separate gates. Absence does not identify a provider fault or prove lack of support. Re-entry requires immutable receipts, placeholder identifiers, no secrets or real users, deny-all provider egress, and intercepted config/authentication effects.
Related guides: Settings overview · Settings logs