Feature Request: Allow ESPHome API & MQTT to run simultaneously (ESP32-focused)

[dougle03]

Describe your core improvement

Summary
Currently ESPHome prevents enabling both the native API and MQTT in the same config.
This limitation appears to be design-based rather than a hard technical restriction — both components work independently, and the block comes from configuration validation.

I’m requesting an opt-in option to allow both to run together, particularly on ESP32 devices, where CPU and memory constraints are minimal compared to ESP8266.

Current limitations

Use Case
Many ESPHome users integrate devices with Home Assistant via the API for low latency and native features. However, when Home Assistant is down (maintenance, restart, or failure), those devices become unreachable.

Allowing MQTT to run in parallel provides:

A resilient fallback path for local automation systems (e.g., Node-RED)

Continuous telemetry logging even when HA is offline

A migration bridge when moving from one broker/system to another

Example scenario:

Normal operation: API → Home Assistant

Fallback: MQTT → Node-RED automations keep working during HA downtime

Technical benefits

Why This Should Be Considered

ESP32 hardware easily handles both stacks in parallel without stability issues in testing

Limiting to ESP32 (or warning on ESP8266) addresses performance concerns

Marking it as an advanced / unsupported option avoids extra testing burden for default users

This change would require minimal code modification — just removing the mutual exclusion in config validation, leaving actual component behaviour unchanged

Additional context

Proposed Approach

Add a YAML flag such as allow_mqtt_and_api: true under esphome:

Restrict usage to ESP32 targets or log a warning for ESP8266

Keep default behaviour unchanged

References

Multiple forum and Discord requests for this capability

Similar functionality works fine when MQTT is added indirectly via HA, but this adds complexity for the end user

Conclusion
This feature would improve resilience for advanced users without impacting the majority who use API or MQTT exclusively. It’s a small change with potentially big benefits for reliability in mixed-automation environments.

Happy to help test and document the feature if implemented.

[jesserockz]

There is nothing directly preventing both mqtt and api in the same configuration. Maybe you did something else wrong. Please try again and open an issue once you have the actual errors preventing you using both.

[dougle03]

You are right. When did this change? Admittedly it was some years ago the last time I tried, but at that time there was validation errors preventing both mqtt and api in the same yaml....
This is huge news... Thanks.

[randybb]

Nope. I am using api with mqtt together for last 4 years on my nspanels and no issues.

[dougle03]

The original wisdom was that API and MQTT wern't best of friends, especially on 8266 chips...
It used to be in the validation that both can't be configured at the same time, I distinctly remember getting the error when trying years ago...
It seems I'm not keeping up to date enough... lol