Skip to content

SimpliSafe setup fails with 403 Forbidden from api/authCheck after authorization code is returned #183003

Description

@JustinLTW

The problem

The SimpliSafe integration is unable to initialize because SimpliSafe returns HTTP 403 Forbidden from /v1/api/authCheck.

The integration was previously configured and working. It began failing to set up with a 403 response from api/authCheck while Home Assistant was using the existing stored refresh token.

I removed the integration and attempted to add it again from scratch.

The fresh authorization flow appears to complete successfully:

  • Home Assistant generates a new SimpliSafe authorization URL.
  • SimpliSafe login succeeds.
  • SMS MFA succeeds.
  • The browser reaches the com.simplisafe.mobile callback URL and returns a new authorization code.
  • I paste that fresh authorization code into Home Assistant.

Home Assistant then displays "Unknown error occurred."

The log shows that API.async_from_auth() proceeds to _async_post_init(), which calls api/authCheck. SimpliSafe immediately responds with HTTP 403 Forbidden.

I have repeated the authorization process using fresh Home Assistant-generated URLs and fresh one-time authorization codes. The result is consistently the same.

The official SimpliSafe mobile app continues to work normally with the same account.

What version of Home Assistant Core has the issue?

core-2026.9.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

SimpliSafe

Link to integration documentation on our website

https://www.home-assistant.io/integrations/simplisafe

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

File "/usr/src/homeassistant/homeassistant/components/simplisafe/config_flow.py", line 117, in async_step_user
    simplisafe = await API.async_from_auth(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
    )
    ^
File "/usr/local/lib/python3.14/site-packages/simplipy/api.py", line 147, in async_from_auth
    await api._async_post_init()
File "/usr/local/lib/python3.14/site-packages/simplipy/api.py", line 202, in _async_post_init
    auth_check_resp = await self._async_api_request("get", "api/authCheck")
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/simplipy/api.py", line 251, in _async_api_request
    resp.raise_for_status()
    ~~~~~~~~~~~~~~~~~~~~~^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 655, in raise_for_status
    raise ClientResponseError(
    ...<5 lines>...
    )
aiohttp.client_exceptions.ClientResponseError: 403, message='Forbidden', url='https://api.simplisafe.com/v1/api/authCheck'

Additional information

The SimpliSafe integration was previously configured and working. It began failing with HTTP 403 Forbidden from /v1/api/authCheck.

I removed the integration and attempted to add it again from scratch. The SimpliSafe authorization flow completes successfully: login succeeds, SMS MFA succeeds, and the browser returns a fresh com.simplisafe.mobile callback authorization code.

After entering that fresh authorization code into Home Assistant, Home Assistant displays "Unknown error occurred."

The log shows the setup reaching API.async_from_auth(), then _async_post_init(), which calls /v1/api/authCheck. SimpliSafe returns HTTP 403 Forbidden.

The official SimpliSafe mobile app continues to work normally with the same account.

I repeated the setup using fresh Home Assistant-generated authorization URLs and fresh one-time authorization codes, including after clearing SimpliSafe browser site data and bypassing the biometric/passkey login path. Each attempt fails at the same /v1/api/authCheck request with HTTP 403.

This appears similar to:
#170547
#109609

Issue #170547 contains the same 403 Forbidden response from /v1/api/authCheck but was closed without an apparent linked fix.

This appears different from:
#178577

In #178577, the authentication flow fails before an authorization code is returned. In this case, a fresh callback authorization code is successfully returned and the failure occurs afterward during api/authCheck.

Activity

  1. home-assistant commented on Sep 23, 2026

    @home-assistant
    Contributor

    Hey there @bachya, mind taking a look at this issue as it has been labeled with an integration (simplisafe) you are listed as a code owner for? Thanks!

    Code owner commands

    Code owners of simplisafe can trigger bot actions by commenting:

    • @home-assistant close Closes the issue.
    • @home-assistant rename Awesome new title Renames the issue.
    • @home-assistant reopen Reopen the issue.
    • @home-assistant unassign simplisafe Removes the current integration label and assignees on the issue, add the integration domain after the command.
    • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the issue.
    • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the issue.

    (message by CodeOwnersMention)


    @JustinLTW Thanks for reporting this issue!

    Before we dive in, please make sure this isn't a duplicate by searching through existing issues. Also check recently closed issues, as your problem might already be fixed but not yet released.

    https://github.com/home-assistant/core/issues?q=%20label%3A%22integration%3A%20simplisafe%22%20
    (message by IssueContext)


    simplisafe documentation
    simplisafe source
    (message by IssueLinks)

  2. Valiante commented on Sep 25, 2026

    @Valiante

    Seeing the same on 2026.9.3 (HAOS), plus the runtime side of it, which I think points to a fix that's already released.

    What happens

    After about 6 hours of normal running, the 30-second subscription poll and arm/disarm calls start returning 403 and never recover:

    ERROR (MainThread) [simplipy] Giving up _async_api_request(...) after 1 tries (aiohttp.client_exceptions.ClientResponseError: 403, message='Forbidden', url='https://api.simplisafe.com/v1/users/<id>/subscriptions?activeOnly=true')
    
    • Entities keep their last state, so it isn't obvious until an arm fails.
    • Token refreshes don't help. The last 401 detected; attempting refresh token succeeded 11 minutes before the 403s started.
    • Reloading the integration then fails at api/authCheck with a 403, the same as this issue.
    • A full HA restart fixes it every time, and the SimpliSafe app works throughout.

    Likely cause and fix

    This matches bachya/simplisafe-python#1177: stale AWSALB / AWSALBCORS load-balancer cookies persist in HA's shared aiohttp session. They survive token refreshes and integration reloads, and only clear on restart.

    That fix was released in simplisafe-python 2026.09.0 on 8 Sep, but HA 2026.9 still pins 2026.06.0 (#180419).

    Ask

    @bachya would a bump to 2026.09.0 be possible, ideally in a 2026.9 patch release?

    @JustinLTW does a full HA restart (not just removing and re-adding the integration) let the setup complete for you? If so, it's probably the same cookie issue.

  3. milnivlek commented on Sep 27, 2026

    @milnivlek

    I'm not the OP. But for what it's worth, I also started experiencing these 403 Forbidden errors yesterday with my existing Simplisafe integration. And restarting HA did resolve these errors.

  4. Tregaron1 commented on Oct 5, 2026

    @Tregaron1

    Potentially related on HA Core 2026.9.2 / HAOS 18.2: on 5 October, the SimpliSafe integration remained loaded, but alarm_control_panel.alarm_disarm returned HTTP 403 Forbidden at /v1/ss3/subscriptions/<redacted>/state/off. The alarm entity remained armed_home, and the calling script stopped at that action.

    Restarting Home Assistant Core, rather than rebooting HAOS, restored successful disarming. This is one observed recovery; recurrence is unknown. Unlike the original report, this failure occurred during a disarm request from an already-loaded integration, rather than during /api/authCheck at setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Fields

Priority

None yet

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions