Skip to content

403 "APIGW-403" on v2/vehicle/guid immediately after successful token refresh (starting 2026-07-29) #187

Description

@Spinak627

Summary

As of ~08:14 ET on 2026-07-29, both of my config entries fail setup with a 403 from GET https://onecdn.telematicsct.com/oneapi/v2/vehicle/guid.

The OAuth token refresh succeeds immediately before the failing call, so this does not appear to be a credential or account problem. The Toyota/Lexus mobile app works normally for both accounts throughout.

Environment

  • Integration: 2.6.12 (latest in HACS)
  • HA Core: 2026.7.4
  • HA OS: 18.1
  • Vehicles: 2026 Lexus IS 350, 2025 Lexus IS 350
  • Config entries: 2, each using a separate Toyota/Lexus account

Log (debug enabled)

2026-07-29 08:44:36.440 INFO  [custom_components.toyota_na] Tokens refreshed, updating ConfigEntry
2026-07-29 08:44:36.465 DEBUG [custom_components.toyota_na] Updating vehicle status
2026-07-29 08:44:36.767 DEBUG [custom_components.toyota_na.patch_client] Toyota API error:
  GET https://onecdn.telematicsct.com/oneapi/v2/vehicle/guid -> 403 Forbidden | Response:
{
  "status": {
    "messages": [
      {
        "responseCode": "APIGW-403",
        "description": "Unauthorized",
        "detailedDescription": ""Forbidden""
      }
    ]
  }
}

Followed by UpdateFailed -> ConfigEntryNotReady -> retry loop.

What I've ruled out

Account / subscription - two independent Toyota accounts, both fail identically within the same second. Both accounts fully functional in the mobile app (remote start, location, odometer all updating normally today).

Credentials / stored token - "Tokens refreshed, updating ConfigEntry" logs success ~300ms before the 403. Auth server accepts the refresh token; the gateway rejects the next call.

IP / edge block - an unauthenticated request to the same URL returns a different response, so the gateway is evaluating requests rather than dropping them at the edge:

$ curl -isS https://onecdn.telematicsct.com/oneapi/v2/vehicle/guid
HTTP/2 401
x-amzn-errortype: UnauthorizedException
via: 1.1 ...cloudfront.net (CloudFront)

{"status":{"messages":[{"responseCode":"APIGW-401","description":"Unauthorized",
"detailedDescription":"Invalid API Key or Missing Authorization Header"}]}}

Stale X-APPVERSION - _auth_headers() sends 3.1.0; the current Toyota app is 3.4.0. Bumped both occurrences in patch_client.py to 3.4.0 and restarted. No change, identical 403. Reverted.

Observation

The gateway advertises this accepted header set in access-control-allow-headers on the 401 response:

guid, x-channel, x-brand, accept, email, content-type, phone, x-correlationid,
hw-type, region, accept-encoding, generation, datetime, asi-code, language, imei, vin

_auth_headers() appears to satisfy all applicable ones (X-API-KEY, X-GUID, X-CHANNEL: ONEAPP, X-BRAND: T, x-region: US, X-LOCALE, User-Agent).

The doubled quotes in "detailedDescription": ""Forbidden"" look like Toyota's error wrapper embedding a raw "Forbidden" string - which is AWS API Gateway's stock response for an invalid or inactive API key on a method that requires one. That points at X-API-KEY (currently sourced from the toyota-na package on PyPI, last released 2.1.1 in May 2022) rather than anything user-side, though I can't confirm that from outside.

Happy to run any further diagnostics.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions