These patterns come from real firmware that consumes this WiFiManager fork. They describe the boundary between a product application and WiFiManager; they are not additional framework APIs and do not require a cloud service or companion app.

Scenario	Start here when…
Field installer provisioning	A physical device needs a deliberately bounded setup window on site.
Product settings and Wi-Fi	The portal collects Wi-Fi and application-owned settings together.
Primary and fallback Wi-Fi	A deployment supplies a candidate primary/fallback network that must be verified before storage.
Local web-service handoff	The application already owns port 80 when recovery provisioning may begin.
Provisioning state feedback	LEDs, a display, or logs need to distinguish setup, recovery, and connected states.

The normal Basic Portal example remains the shortest way to try the legacy saved-network-or-portal flow. These recipes explain the product concerns that a standalone example should not pretend to solve.

Back to documentation · project overview.