Tesla is about to close non-fleet API starting April 2024

[KrzysztofHajdamowicz]

https://developer.tesla.com/docs/fleet-api#2024-03-26-shutting-down-legacy-vehicle-api-endpoints

News from three days ago

[tjhart]

How does this impact Teslamate?

[brianmay]

I am having problems interpreting what they are saying.

Fleet API is Tesla's official 3rd party API and the only supported API for vehicle interactions.

This implies that the owners API which we are using is not supported. OK, nothing new here, we knew that already.

The list of available endpoints can be found at Endpoints and Regional Requirements.

You should only use documented APIs. I presume this excludes the owners API.

Starting April 2024, any vehicle APIs not part of this list will be phased out.

Non-documented APIs, including owners API will be phased out.

Per the Fleet API policies, continued usage of unsupported APIs will result in the revocation of Fleet API access privileges.

Huh? But we don't have feel API access privileges. How can you revoke something we don't have? Maybe this is aimed at somebody using both old and new. Not sure why you would do that. Or why it would require revocation of privileges as opposed to just blocking the bad requests.

Reading between the lines suggests that they might start blocking tokens that Teslamate uses. But they haven't actually said that.

Nor is there anyway to contact anybody to get additional information or clarification on these requirements.

The good news:

• There is nothing here that says we have to transition to the new end to end encrypted command API.

• The fleet API is very similar to the owners API, transitioning across should not be technically hard.

The bad news:

• Getting tokens that work with the fleet API requires registering as a developer and agreeing to there terms and conditions (which looked very dodgy when I read them) and keeping your oauth secrets - secret. This may not be feasible for an open source project like Teslamate.

• Might have to introduce processing for 429 rate limit errors (???). Rate limits are poorly documented. Rate limits as documented are very low.

(Not that it affects teslamate, but only 5 wake up requests a day? But it can take more then 5 wake up requests to wake the car up even once! For even a simple usage like my program that charges the car at cheap times that is unusable).

I have no drama with Tesla replacing old undocumented APIs with new documented APIs. What I do have an issue with is that the new APIs are heavily restricted compared with what we could do with the old APIs. For me, one of the key advantages of Tesla over other cars was its APIs, but if this disappears I think if I ever need another car I will be seriously looking at Tesla's competitors now. But none of this is surprising considering evidence is that Elon Musk sees APIs as easy way to get extra money.

At least there is some good news for me, the Amber electricity retailer (Australia) is experimenting with talking to the Tesla API for charging at cheap times. Maybe if my code stops working, one day I can use Amber's code and let them deal with this crap. But this won't help for Teslamate.

[brianmay]

At the bottom of that page, there is an email address: fleetapisupport@tesla.com

While it is clear that this is intended for technical support queries, it is the only contact we have. Maybe somebody needs to contact this address and ask (very tactfully) "Have you considered open source software requirements? Are you actively trying to kill open source projects that use your APIs?". Perhaps we don't want to mention Teslamate just yet though....?

No doubt they don't care. But might be worth contacting them regardless, that way they can't claim in the future there was no interest.

[brianmay]

I asked copilot for advice. Its advice does actually seem reasonable.

Prompt

Tesla is updating their APIs to require developers have an account and obtain application specific secrets to talk to the API. But this won't work for open source software, which is publicly available and as such cannot be published with any secrets. How do I tactfully contact Tesla and ask if they intend to kill off open source software that uses their APIs? The only contact I have is a technical support contact at fleetapisupport@tesla.com.

Response

Certainly! It’s important to approach this situation tactfully. Here are some steps you can take to inquire about Tesla’s intentions regarding open source software and their APIs:

1. Compose a Professional Email:
   Write a polite and respectful email to the technical support contact at fleetapisupport@tesla.com.
   Introduce yourself briefly and explain your interest in Tesla’s APIs.
   Clearly express your concern about the impact of the recent API updates on open source software.

2. State Your Concerns:
   Explain that the new requirement for application-specific secrets poses challenges for open source projects.
   Emphasize that open source software cannot include secrets due to its public nature.
   Mention that this change might hinder the development and maintenance of open source Tesla-related projects.

3. Ask for Clarification:
   Politely inquire whether Tesla has considered the implications for open source developers.
   Ask if there are any alternative solutions or exemptions for open source projects.
   Express your hope that Tesla will continue to support the open source community.

4. Suggest Collaboration:
   Propose collaboration between Tesla and open source developers.
   Highlight the benefits of having a thriving ecosystem of third-party apps and tools.
   Suggest exploring ways to address security concerns without compromising open source principles.

5. Thank Them for Their Time:
   Conclude your email by expressing gratitude for their attention and consideration.
   Provide your contact information in case they wish to discuss further.

Remember to maintain a respectful tone throughout your communication. Tesla may appreciate feedback from the developer community, and your inquiry could lead to positive changes or clarifications regarding their API policies. Good luck!

Links

https://www.tesla.com/developer-docs
https://electrek.co/2023/10/12/tesla-releases-official-api-documentation-support-third-party-apps/
https://interestingengineering.com/transportation/tesla-finally-supports-third-party-apps-with-official-api
https://www.notateslaapp.com/news/1653/tesla-creates-official-apis-for-third-party-services-to-start-charging-for-usage

[eliluong]

I recently saw a post about Teslemetry, which gives something like API access/data.

They are charging for it, obviously. But I wonder if Tesla charges to get access to use the API itself, or Teslemetry is charging for their services.

[eliluong]

I feel more comfortable paying you folks the subscription fee to develop and maintain the API bridge/proxy, rather then relying on a third party. But I guess it is easier to utilize what they have made already than replicate the same work.

[brianmay]

From the FAQ:

Does using Teslemetry keep my vehicle awake?
For Cybertruck, Model 3/Y, and newer Model S/X vehicles with a 2024 or newer update, Teslemetry will not keep your vehicle awake even with frequent polling or with Telemetry enabled. However pre-2021 Model S/X vehicles may not support all features, and may stay awake due to frequent polling.

I imagine this means MCU1 cars that have not been upgraded to MCU2 will resort to polling.

[brianmay]

Also from the same page:

Known Issues
#knownissues

Tesla Fleet Telemetry requires OWNER access to the vehicle. If you have DRIVER access, you will not be able to use the Webhooks, or Server Side Events.
Older Model S and Model X vehicles do not support Fleet Telemetry at all.
Vehicles only supports a single Fleet Telemetry configuration. Starting Fleet Telemetry will stop it working for all other services.

The first point probably won't affect us. The second point might be significant. I think the third point means if you can't point telemetry (for example) at home assistant and teslamate at the same time.

[brianmay]

I feel more comfortable paying you folks the subscription fee to develop and maintain the API bridge/proxy, rather then relying on a third party. But I guess it is easier to utilize what they have made already than replicate the same work.

There is a lot more then just a simple API bridge/proxy. There is also:

• The work in keeping this up-to-date with Tesla's latest whims and demands.
• Trying to reproduce the work to stream these values without stopping the car from going to sleep. Not sure how they do this. I can't see anything in the fleet API docs.
• Legal liability. What happens if somebody finds a vulnerability somewhere, breaks into the server, and somehow uses that to steal Teslas? Even if Teslas aren't stolen, but personal data is stolen that could in itself raise all sorts of liability issues.

[Bre77]

Teslemetry Admin here
@brianmay you can point Teslemetry to multiple places (via webhooks and/or SSE), but you cant point Tesla Fleet Telemetry to multiple third parties. I'd be willing to add MQTT support if there is demand.

[brianmay]

Question: Are there any metrics TeslaMate uses that are not on this list? https://teslemetry.com/docs#fields - if there are we need to know sooner rather then later :-)

[Bre77]

The fleet telemetry field list is defintely too limited for most usecases I have, but I am not a Teslamate user.

[bmerciergallay]

what is most unclear is if tomorrow all ends or not in teslamate...
Teslamate, as of now, is not adapted to any new way of fetching datas, so if Tesla closes the API tomorrow, Teslamate is kinda dead...
Tessie and TeslaFI allow to import teslamate datas, but what about the other way around if teslamate gets back on track with new APIs/methods only after a few month ? Will we forever have these months blank ?

[KrzysztofHajdamowicz]

As a quick solution, maybe Teslamate can implement communication over Fleet API proxy, like Home Assistant Tesla integration?
alandtse/tesla@730a206

Some users might already have proxy running, others can spawn their instance.

The quicker we left Owner API, the less chance of repercussions for Teslamate users.

[brianmay]

As mentioned above the problem here - as far as I am aware - the streaming API is not part of the owners API or the fleet API. At least there is nothing about streaming documented that I can see. So I think the streaming API that TeslaMate uses will not be supported.

There is a reference to fleet telemetry - but a bit unclear how this fits in. Suspect it is nothing like the streaming API that Teslamate uses in any case.

Forgot to mention in the above that non-keeping the car awake only works for newer cars, will add that.

[brianmay]

Also note that a (current) limitation of Teslemetry telemetry is that the feed can only be directed in one place at a time (if I understand this correctly). So no sending the feed to Teslamate and Home Assistant. I would imagine sending the feed to Teslamate, publishing data on MQTT, then Home Assistant can pick it up - same as now.

[KrzysztofHajdamowicz]

Also note that a (current) limitation of Teslemetry telemetry is that the feed can only be directed in one place at a time (if I understand this correctly). So no sending the feed to Teslamate and Home Assistant. I would imagine sending the feed to Teslamate, publishing data on MQTT, then Home Assistant can pick it up - same as now.

You can configure which fields you want to stream using Teslemetry web console and all your clients will receive same data over stream connection.
But yes, it would be great if Teslamate can pick up values published by HA (with Teslemetry integration) over MQTT and vice versa. That's something that would require coordination and agreement with Teslemetry integration author

[Bre77]

@brianmay @KrzysztofHajdamowicz I'd be open to adding MQTT as a transport in Teslemetry for the Fleet Telemetry data. I have done work in that space many years ago, so dont see why not.

[brianmay]

I have been told that MCU1 cars will not work with the newer Fleet Telemetry API.

Not yet sure about MCU2 cars.

MCU3 cars will work 100%.

Note that the Fleet Telemetry API is different to the Tesla Fleet API. The Telemetry API is streaming, the other one is sending requests on demand.

[brianmay]

There seems to be growing evidence that the fleet telemetry API - and this also means the Teslemetry streaming API - will not work with MCU2 cars. At least my car (A 2016 Model S upgraded to MUC2) fails trying to register the required virtual key with my car. And attempting to start streaming on Teslemetry fails.

Which in turn means there isn't anything I can do for implementing something that will support the fleet telemetry API. Not unless somebody wants to donate me a MCU3 based car ;-)

[eliluong]

Does this mean they have to let MCU2 support the old APIs, they can't take it away :)

[brianmay]

MCU2 may or may not be supported later on this year. teslamotors/fleet-telemetry#121

[brianmay]

The way I see it we have the following options (now):

1. fleet API + old streaming API
2. fleet API + fleet telemetry
3. fleet API + polliing
4. telemetry API + old streaming API
5. telemetry API + new streaming API
6. telemetry API + polliing

1 might work but is risky, "Per the Fleet API policies, continued usage of unsupported APIs will result in the revocation of Fleet API access privileges.", which would mean lose of developers account.

4 old streaming API not available from telemetry and probably won't happen due to Tesla threat (above) of revocation of privileges.

2 + 5. Currently requires MCU3, which I don't have. Possibly MCU2 support will come in the future, but this is not certain.

That leaves 3 (requires a dev account) and 6 (doesn't require a dev account).

6 does require a bit more changes though, currently we have logic for renewing tokens, storing tokens in the database, etc. None of is required or wanted, teslemetry tokens do not expire. All we need is to put the token in an environment variable before starting and use this when making a request. And we would need to delete/disable the streaming.

We will have to watch carefully for rate limiting. Which will be kind of yuck compared with what we have, but better then not having anything at all (if they do decide to kill off the owners API.

I am not happy with Tesla's decision to kill of the old streaming API when there isn't a suitable replacement. But I guess maybe nobody at Tesla has even realised this.

[jlestel]

Hi @brianmay,

Agree on possible options.

To anticipate possible future changes and provide a simple free alternative to TeslaMate users, I have made access to the Fleet API free on https://app.myteslamate.com

Simply sign up with a Tesla account and go to this page to try API Fleet.

Users can also associate with the Telemetry API for free on this page but it does not replace the old streaming API for the moment...
Given the legacy of the project, does it makes sense to make a "compatible old streaming API" from the Telemetry API?

[cwanja]

Curious - are you currently using this repo as a base for all your users and if so, what happens if / when this code base goes away? Are you going to take over development then with this service?

[jlestel]

To use the new API, Tesla repos are used. The paid hosting service works with a fork of this repo which uses the Fleet API replacing the old API and retains the streaming API.

My skills are limited to evolve the elixir code, if the code base goes away, the service will stop. This is why I was thinking of making a wss similar to the old streaming API from the new Telemetry API.

[cwanja]

What coding language is the service? Assuming web based, Angular, React, HTML, CSS (dating myself). Are you holding back contribution back to this repo to upgrade to the Fleet API due to Elixir?

Fully admit - I am not proficient at all in Elixir. And have not dug into the Fleet API documentation.

[jlestel]

The web is PHP and especially HELM then.

The Fleet API is similar to the API part used currently by TeslaMate. It works changing the endpoints and adding "official" API tokens in the environment.

I'll upgrade the contribution because I was using specifics keys for new API renewed regularly by PHP for the moment and I'll switch to the Fleet API that I was talking about initially so that it can work on any env without having to create a Tesla developer account, manage these keys, etc.

[mattenz]

Forgive my possible ignorance here, but wouldn't the paid cloud services like TeslaFi, Tessie, etc be using this new Fleet Telemetry API? Since they "pull" the same data that Teslamate "pulls", doesn't that mean the new API should have the same functionality as the streaming API that is currently being used?

As an individual, it's not overly difficult to set up a dev account with Tesla to interact with the new Fleet API, I've done it for the Fleet Command API with the Tesla HTTP Proxy docker image for use in HA.

[mattenz]

Sorry, I wasn’t meaning that TeslaMate should use that exact project and make use of the Fleet Command API but rather do something similar with the new Fleet Streaming API instead.

As for the “legacy” vehicles and the unofficial older streaming API, I might pose the question on Tesla’s git page and see if they’ll answer with what their stance is on that.

[bmerciergallay]

Closest thing to streaming api must be fleet telemetry.

[mattenz]

Yes, Fleet Telemetry API is what I was meaning rather than Fleet Streaming API…it’s late here 🙂

[Bre77]

Yes, Fleet Telemetry API is what I was meaning rather than Fleet Streaming API…it’s late here 🙂

As Brian has said, Fleet Telemetry doesn't support MCU1 or MCU2 vehicles, and it's much more difficult to self host than polling the Fleet API.

[mattenz]

I think the main difficulty I see with self-hosting Fleet Telemetry is people securing it correctly.

[kiler129]

So to summarize, as I think the information is spread all over currently, we have the options as summarized below, to communicate with the vehicle as of 2024/05/13. Please correct me on any points. I attempted to link sources where possible.

Tesla's Owner API (aka "Tesla Owners API")

• Support: Unofficial/unsupported by Tesla, but widely documented by volunteers
• Authentication:
  • Requires OAuth token with DRIVER or OWNER permission
  • No additional steps are required
• Scope: All entities in the account (cars & energy products)
• Products: Supports all MCUs & cars to date, regardless of the mfg date
• Capabilities
  • Polling of all vehicle parameters¹
  • Streaming data from all vehicles²
    • Allows multiple clients to get the stream of data
    • Data is streamed from the car to Tesla and from Tesla to our application
  • Performing actions ("commands" per Tesla) ³
    • Pre-2021 MS and MX: full support
    • Other vehicles: blocked; must use Tesla Vehicle Command protocol & SDK ⁴
• Access:
  • Free
  • Doesn't require any registration nor EULA
  • Has undocumented but sufficient usage limits
• Barrier of entry
  • Very simple for users; rather simple for developers
  • User must provide Refresh Token (e.g. from popular Auth app for Tesla)⁵
  • Requires simple HTTP client
• Technical details
  • All requests are send over internet via Tesla cloud servers
  • Uses REST to send commands and open streaming channel

Tesla Fleet API

• Support: Officially supported and documented
• Authentication:
  • Requires OAuth token as per official docs
  • Tokens are scoped
• Scope: All entities in the account from a given category requested when authorization is requested from the enduser
• Products: Supports all MCUs & cars to date, regardless of the mfg date
• Capabilities
  • Polling of all vehicle parameters¹
  • No streaming data support
  • Performing actions ("commands" per Tesla)
    • Pre-2021 MS and MX: full support via REST endpoint
    • Other vehicles: not supported; must use Tesla Vehicle Command protocol & SDK ³; migration pathway exists using official Tesla's HTTP Proxy
    • Note: sending commands require per-vehicle authorization by the user
• Access:
  • Free for now
  • Based on Membership Tiers section, it will be paid
  • Low usage limits in the current state
  • All users bound by EULA, with official wording in updates strongly suggesting that anyone who accepts the Fleet API EULA can have their Fleet API access revoked if found of using unsupported APIs (i.e. Tesla Owner API)
• Barrier of entry
  • Hard for users; very simple for developers
  • Requires developer's account per application, which means every user of an open-source self-hosted project (like TeslaMate) needs to go through that process
  • Requires publicly-accessible HTTP server with a domain, hosting a small key file ⁶, posing a significant challenge for regular users
  • Requires simple HTTP client to query the data
• Technical details
  • All requests are send over internet via Tesla cloud servers
  • Uses REST to send commands
  • It appears roughly similar to Owners API but with additional security and no streaming (or a completely rebuilt streaming, as described below)

Tesla Fleet Telemetry

(mainly what TeslaMate would be interested in using)

• Support: Officially supported but not documented but with reference implementation available
• Authentication:
  • complex; officially part of Fleet API; see Fleet API section
  • Only available for OWNER accounts; DRIVER support coming soon
• Scope: Only specifically authorized entities (e.g. cars) are allowed to be commanded; user can easily revoke access
• Products: complex, see below
• Capabilities:
  • Access to live telemetry only
  • Pre-2021 MS and MX, any MCU1/Tegra cars: not supported and no plans for support, streaming supported via unofficial Tesla's Owner API
  • MCU2/Intel cars: not supported yet, may be supported in 2024
  • MCU3/AMD cars: fully supported
  • Energy products: ???
• Access:
  • Free for now
  • No official communication as to limits or pricing⁷
  • The current limit, presently undocumented but historically listed, is claimed to be 10 fields/min
• Barrier of entry (self-hosted project perspective)
  • Very hard for users; hard for developers
  • Users
    • Requires developer's account per application, which means every user of an open-source self-hosted project (like TeslaMate) needs to go through that process
    • Requires publicly-accessible HTTP server with a domain, hosting a small key file ⁶, posing a significant challenge for regular users
    • Requires secured & stable publicly-accessible TLS server where vehicles stream data directly
    • Only a single telemetry-collecting/streaming server is supported
  • Developers
    • New applications are encouraged to use official SDK available as a executable binary with a sane interface handling everything
    • Tesla provides official telemetry server/collector implementation
• Technical details
  • Data is streamed directly to a single user's telemetry server
  • Tesla specifically warns about vehicle key compromise it's clear the Tesla cloud isn't a part of the data flow
  • There's an unmerged PR in the Fleet Telemetry repo, with more documentation

3rd-party APIs

I specifically didn't dig into 3rd-party API providers. Relying on a 3rd party service to provide an "API proxy" service is in my opinion problematic in multiple ways:

• Creates another layer of complexity in terms of capabilities, data format/stability, availability etc
• Another place where security of the vehicle can be compromised
• Another entity that has access to the data, with separate EULA and privacy policy
• Additional service that is/will be charging users (as in the end of the day these are operating businesses)
• Any changes to the official API will need to be implemented by the 3rd party first [Update: in certain cases; see discussion below]
• The overall future of access to the data then lies not only in the Tesla providing access but also given 3rd party existing

After working for years in the industry with payment providers, I also already foresee the issues of "it's not me!" problem: there's additional code, additional layer of client library, and I unfortunately expect the official API support to be always blame the 3rd party for access issues.

Challenges summary

• All official APIs are complex for users

  • Developer's account creation is easy
  • Buying a domain and getting SSL on it is an intermediate challenge
  • SAFELY hosting a server for even the key file and more so the telemetry is quite challenging and issues brought by users in the unofficial HomeAssistant addon bringing the Tesla Vehicle Command HTTP Proxy into HA are a great proof of that. I am not even talking about the idea of hosting such a service in the same place as HA, but that's besides the point as I didn't evaluate that addon.

• Apps like TeslaMate need access to streaming API

  • Tesla Fleet Telemetry support for different vehicles is complicated, as noted above, excluding many people
  • Even significant TeslaMate contributors like @brianmay don't have access to a supported car to use the official TFT API
  • Migration to using polling will be a huge degradation in TeslaMate functionality as a whole.
  • Migrating to unofficial polling API is imo a bad idea. Having worked with projects at scale, Tesla gives clear signs of Owner API being slowly phased out and more and more things being replaced. It will most likely go away.
  • Migration to official polling API (Fleet API) is also a bad idea as it's clearly not intended for that¹

• Streaming is a mess problem now

  • Current unofficial streaming API is still available.... for now. It will most likely achieve the same state as using REST commands (i.e. if the car supports new Vehicle Commands SDK it must use it) ⁴
  • Usage of unofficial streaming API (as part of Tesla's Owner API), even if technically possible, is problematic legally going forward. As users who want to use either Fleet API or Vehicle Command SDK must sign the EULA that specifically prohibits using unofficial APIs with a threat of access to official APIs being revoked.
  • Figuring out how to let users safely host the public key file for Fleet API is easy; it can be even a one-click deployment as CloudFlare worker.
  • While I'm personally happy for the significant security improvements and the possibility of directly streaming of data to my server, every coin has two sides:
    • Asking users to host a telemetry server is a significant step-up
    • Many users are behind CGNAT making it impossible to host the server at home
    • As telemetry is streamed from the vehicle directly, Tesla imposes a limitation of one user/fleet-owned telemetry server per vehicle. This means applications like TeslaMate cannot really "own" the datastream as even using HA and TeslaMate will be a problem.

• It's [probably] all about the money

  • I know many users hammering the Owners API... I even know a person who had their access to all remote tesla services revoked (i.e. they cannot even use the official app)
  • There are a lot of users utilizing multiple connections to the streaming API (TeslaMate, HA, various 3rd party not-self-hosted apps), which is most likely not cheap. Given that Tesla, unlike other car manufacturer's, don't charge for online access to the car they cover that cost and it's possible it became unreasonable as the usage scaled.
  • Given Elon's API pricing changes in Twitter X, I wouldn't be surprised if Tesla's APIs were seen as good place to earn money
  • There are many 3rd party services that built their whole business around accessing Tesla API en-masse:
    • They're doing this for free
    • Access is done with little-to-no oversight of how the API is used. As reported by users and in a lawsuit not everyone can behave nicely.
    • I'm naturally not saying these apps provide no value - quite the opposite, they're amazing! However, if any developer's resources and/or server resources are spent on the Tesla side, where a 3rd party charges a fee.... it's a bit of a problem business-wise.
  • Some requests cost Tesla real money immediately, like sending an SMS to wake up the car

---

The way forward?

In my opinion, TeslaMate's way forward would be to:

• Allow user's to select data source:
  • Leave the current data pipeline, to support <2021 MS & MX and all other MCU1 cars
  • Implement sourcing data from Kafka, in a format as the official Tesla Fleet Telemetry reference server implementation produces.
• Allow configuring the REST API & Kafka server addresses
  • Users can use the Tesla Vehicle Command HTTP Proxy server on their own
  • MS & MX <2021 will be able to point it to Owners API at their own risk(?)
  • I'm not sure of the changes needed to use Fleet vs Owners API as far as TeslaMate uses, but it appears that it should be a 1:1 replacement with proxy. Tesla's code simply forwards requests to Fleet API that aren't commands but with the proxy's OAuth context. The /vehicle_data from Owners API appears to be compatible with Fleet API
  • A 3rd party can provide offering of hosting the Vehicle Command HTTP Proxy as well as Fleet Telemetry server, removing a lot of complexity from the setup for users that aren't able or can't host these on their own.
• Overall, encourage but not force users to host their own Tesla Vehicle Command HTTP Proxy and Tesla Fleet Telemetry servers

That way we will avoid vendor lock-in, while ensuring the solution is as time-stable as possible, as it will use official tooling. In addition, for users who aren't comfortable with hosting their own telemetry server and dealing with keys etc, services like @Bre77's Teslemetry can easily provide Kafka endpoint :) In addition, Kafka unlike e.g. ZeroMQ provides first-class support for data persistency adding to resiliency and allowing 3rd parties to offer additional value-added with their service.

While I am a software engineer with some devops experience, I have zero background in Elixir. Thus, I'm unfortunately unable to help with the implementation. However, I'm resisting myself from writing any middleware/sidecar that runs alongside TeslaMate and attempts to translate from Tesla Fleet Telemetry to anything that TeslaMate understands right now - this would be a very fragile way going forward.

I am positive

All in all, I think what we are seeing are good changes, at least as of today. There are pain points (e.g. support for different cars), and uncertainties around pricing etc. However, at least Tesla didn't start sending lawyers to API users like Ford or to open-source developers like Mazda, or even worse becoming publicly hostile to the community like MyQ.

In addition, I don't believe the overall API changes are malicious, but more an effort of clean-up and actually giving user's a supported and auditable access to the data. Other manufacturer's also had their stories with warranty work being needed due to 3rd party apps. With Tesla's approach to providing service manual for free and open access to service mode in their cars (both quite unprecedented in car world), or sponsoring events on hacking conferences makes me positive to the new direction, even if we're going through a rough transition now :)

Footnotes

Footnotes

1. Per Tesla docs, polling is not intended for M2M usage ("Fetching vehicle data periodically is not recommended (...)") ↩ ↩² ↩³

2. While I wasn't able to find documentation for the stream API itself, many projects rely on ad-hoc reverse engineering of it ↩

3. As the "Owner API" is reverse engineered/not supported, the support for commands isn't guaranteed and no official information is shared about it. Most likely it will follow Fleet API. ↩ ↩²

4. The command REST API via Owner & Fleet APIs was slowly phased out between Q4/2023-Q1/2024 ↩ ↩²

5. Appears to be valid for about a year ↩

6. While the process of obtaining the key is well documented by Tesla, it is ridden with potential issues; see challanges section. ↩ ↩²

7. Most likely will be bussiness-wise part of the Fleet API, i.e. bound by the Membership Tiers ↩

[kiler129]

I did read the whole legal terms before starting Teslemetry, Section 3.3 of the terms allows sublicensing so I believe it's acceptable.

I read them too more carefully now and I don't think reselling API access is permitted. Some excerpts from the terms, with emphasis added by me:

• Ex. 3, §1:
  • “Licensee” means the person or entity identified as the “Licensee” in the Key Terms.
  • “Licensee Vehicle” means a Tesla vehicle owned or leased by Licensee or its Affiliate.
• Ex. 1, §4.3: "Tesla may set and enforce limits on each subscription's use of the API (e.g. limiting the number of API requests or the number of Users)"
• Ex. 1, §4.5 Prohibited Conduct:
  • 4.5.4. Provide API access for any vehicle that is not a Licensee Vehicle.
  • 4.5.7. Rent, lease, sell, sublicense (except as expressly permitted herein), assign, distribute, publish, transfer or otherwise make available the API or Content or User Personal Data or Vehicle Data to any third party other than to Users in the Application.
• Ex. 1, §3. Sublicenses: Licensee may sublicense its rights under this § 3 to one or more third party services providers within the Territory, to the extent Licensee owns each Licensee Vehicle and each such services provider agrees in writing to be bound to all of the terms and restrictions contained in this Agreement

To me this reads like one of many agreements I've seen that prohibits sublicensing. The API appears to be geared towards creating apps for fleet owners (think e.g. car rental scenario), with a bit of bending for end-user self-hosted for their own vehicles. They specifically say you [as the person who signed up for the API access!] is not allowed to access data of vehicles they don't own/lease. This already may be a challenge for apps like TeslaFi.
There's a clear indication of sublicensing being prohibited with exception of cases listed in exhibit 1 §3. Reading this point carefully this doesn't seem to apply to situation where licensee provides access to the API via some proxy, but rather a company like Uber applying for license and paying for it and then linking their fleet access with some other provider.

Again, IANAL, but I think a workaround would be that your users have to apply for their own license under a domain like user1234.keys.teslemetry.com and then by some process provide your app an access so that they can use teslametry as a frontend for the streaming. That way it's the user who own the vehicle sublicensing API to you, which appears to be allowed, as long as you agree to Tesla terms, rather than you sublicensing your access and adding vehicles you don't own under your license.
I would consult a lawyer on that thou.

[jlestel]

• The current limit, presently undocumented but historically listed, is claimed to be 10 fields/min

Unlike Tessie and Telemetry, MyTeslamate offers a free access to the Tesla API and Telemetry. This is usefull for testing purpose. Third parties only serve as a proxy so it remains the Tesla data that is delivered. So the operation remains similar whatever the third party.

I proposed a PR that allows using third-party API providers, it works correctly with the MyTeslamate free proxy for Tesla API and Telemetry. However, given that the minimum frequency for sending events is 60 seconds in the Tesla Telemetry, the rendering is not really comparable with the Current streaming API.

Moreover, for the moment the real limit displayed in the headers of the Tesla Fleet API responses is 60 calls per hour. This is the same as the current Tesla Owners API. We often see users complaining here about the 429 return codes that trigger when this limit is reached. In summary, TeslaMate under certain conditions appears to call more than 60 times in less than an hour. In this case, the API data is even fresher than what can be obtained with Telemetry. If the Telemetry frequency cannot be reduced, it would be a big regression for Tesla owners used to seeing their data in real time...

[Bre77]

To be clear the Fleet Telemetry limit is max 20 fields, max 10 values per minute. In my experience the Fleet API is not enforcing rate limits, since we poll it every 30s and dont get 429's.

[jlestel]

My bad I got confused. Indeed, we do not see these headers on the new API.

Wahou, every 30 seconds, that seems well outside the limits when they will actually be effective: https://developer.tesla.com/docs/fleet-api#membership-tiers

[kiler129]

I proposed a PR that allows using third-party API providers, it works correctly with the MyTeslamate free proxy for Tesla API and Telemetry.

Thank you for your amazing work! This will allow proxying and potential for centralizing access.

However, given that the minimum frequency for sending events is 60 seconds in the Tesla Telemetry, the rendering is not really comparable with the Current streaming API.
...
To be clear the Fleet Telemetry limit is max 20 fields, max 10 values per minute.

I'm almost sure this is just a "TBD" limit. Tesla most likely uses the same Telemetry protocol and similar/the same code as they published to throw into a Kafka cluster, and their telemetry is realtime-ish. Giving it out to all people is for sure a challenge, so I wouldn't be surprised if limits are set low even just for that reason.

(...) In my experience the Fleet API is not enforcing rate limits, since we poll it every 30s and dont get 429's.

Owners API also is quite.... generous with limits. I think Tesla has more of a "working limits" rather than very strict number of requests. However, I wouldn't hammer it every 30s long-term.

TeslaMate under certain conditions appears to call more than 60 times in less than an hour. In this case, the API data is even fresher than what can be obtained with Telemetry. If the Telemetry frequency cannot be reduced, it would be a big regression for Tesla owners used to seeing their data in real time...

I don't necessarily think getting occasional 429s is a big problem. Even if TM calls API no more than the limit, many people link the API with HA and other tools which will also use up the limit ;)

[brianmay]

I really don't like the Tesla Fleet API agreement you have to agree to. That is why I haven't done so. For example, it says:

4.5. Prohibited Conduct. Any of the following actions (or attempts to do such actions) by Licensee or by any person using Licensee’s Key will constitute a material breach of this Agreement:
...
4.5.10. Use the API for the development of a competing software product or service.

To me this reads as "we will wait until we see merit in what you are doing, develop our own solution, and then claim you are competing with us".

On the topic of charging for access for the APIs, I suspect the vision from the CEO is that large fleets of robo-taxis are sold to big players who are then willing to pay large sums for APIs to manage said fleets. The open source community won't be considered.

Of course if this vision ever becomes reality, that is another question.

[kiler129]

Seconding that as well - I didn't sign up after reading through the ToS. It feels like there's a point where we will be sherlocked potentially. The command deprecation doesn't affect TM, but it significantly crippled HA functionality.

However, I honestly doubt an open-source project will ever register on their radar. If someone decided to sell a service that competes with their service... that's a different story probably. Let's hope we will get some answers soon.

[JakobLichterfeld]

Seems like the API endpoint is really closed now: #3896

[JakobLichterfeld]

Seems to be depending on region for the moment

[bmerciergallay]

If it’s just the dns update time depending on regions : it will be over in less than 48h but you can maybe buy some (little ?) time by changing the endpoints to the ip address…

[js94x]

If it’s just the dns update time depending on regions : it will be over in less than 48h but you can maybe buy some (little ?) time by changing the endpoints to the ip address…

This is unlikely because Tesla is using Akamai CDN which decides request routing based on Host header in HTTP. If you would omit the hostname you will receive an error from Akamai because they do not know where to route your request

[JakobLichterfeld]

Website is pingable, but tokens are not valid anymore. Generation with tesla_auth is possible but TeslaMate do complain about endpoint non exisiting. Seems like API endpoint for my vehicle is shut down

[JakobLichterfeld]

For me a flush dns and reboot solved the issue