I take it as a sign of the current state of hackernews that nearly no one took the time to actually RTFA. This isnt about making apps that run on the car, this is about being able to integrate your external apps with the fleet API. Like, can external app that has permission would be able to locate the vehicle.
That said, I think the security implications are fairly important, since I expect one of the exposed features is to be able to unlock or start the car.
Almost all of this functionality has been available for many years through the reverse engineered API used by the official Tesla app. There is unofficial third party documentation and many third party apps using it are available.
The difference here is that Tesla is creating a new, officially supported API explicitly for third parties, with official documentation, scoped authentication, and a developer program that requires registration (and in the future, payment). Presumably once the SDK is finalized they will start cracking down on apps using the older reverse engineered API.
The only new functionality AFAIK is a push API that allows cars to directly stream information to your server via their cellular connection; previously the information was available but required polling through Tesla's intermediary servers.
I've been doing that for a while with my own car because their API (like other OEM's) is just an OAuth2 REST API with unofficial documentation. So I think this is more "Tesla is launching their developer API documentation and officially letting people develop against it".
Fwiw Tesla's has been the best to work with in my limited experience. Ford's is also decent but the most important remote commands (like start/stop charging) seem to be hidden behind obfuscated endpoints. I spent quite some days trying to reverse engineer them but ultimately gave up.
If you are wondering about the state of auto API's here's a partial list of loads of makes and models that have some form of over the air endpoints via a 3rd party:
Interesting. Home Assistant happened to post about this this afternoon after Mazda’s lawyers rattled sabres about the unofficial Mazda integration; they pointed to Tesla and moreover Audi VW as being much more constructive (including an official home assistant app for VW group’s on-board app platform)
I tried signing up but was rejected. It did mention energy products so it might include it if you gain access.
It looks like they are just doing a free trial to hook in business focused customers so I'm doubtful it would be a good source for personal use when Elon turns on the money spigot.
I'm calling for Tesla to open source all the code running onboard it's vehicles. Consumers have the right to understand how their machines work. Elon, you built an empire off the backs of open source developers. Give back.
> Consumers have the right to understand how their machines work
Windows and macOS aren't open source either and the vast majority of consumers don't care. It would be cool to be able to install an open source third party OS on your car though...
Windows and macOS aren't designed to operate heavy machinery and Linux is a viable alternative. Consumers don't care because they don't know. Consumers who do know, care.
As much as I'd love for that to happen, all of the talk about "Elon mode" leading to potential enforcement action makes me understand why it is unlikely.
It’s better that what people are currently doing. You can cut and paste your auth token into 3rd party services that will give you stats and remote control over your car.
As of 6 months ago there was no way to manually revoke an auth token
I mean, oauth2 is pretty much the standard/best practice for third party access to user-controlled identity and/or resource permissions. I'd like to know more about scopes and how they do authz, but as far as access goes, this has the makings of a best practices implementation like you'd see from Google, reddit, etc. Fine grained access control via scopes, user-facing "you want this app to get access to <list> permissions?" and the ability to later revoke that access.
I'm sure you can find people who'd disagree, but it's far better to build on a standard than something homegrown.
oauth2 was the best practice way to do that back in 2014.
Now, companies like Facebook have discovered the hard way that most users don't think carefully before giving away access to their data. All it takes is one app that says "I'd like access to everything you can see on facebook please", and that's how cambridge analytica happened.
Ever since then, the vast majority of companies have locked down API's - because the company doesn't want to get in legal hot water for the actions of a third party app granted full access by the user.
That doesn't mean oauth2 isn't still the best practice. I'd go as far as saying OIDC is best practice for oauth2 as well.
What you're saying is orthogonal and more about figuring out how to effectively manage users and the accesses they can grant, how easily they can grant certain permisisons, how often they should review access, all that.
Facebook has had issues there, and I'd say Android has also had issues with similarly vague/permissive grants (local-only, completely outside OAuth2), and has learned ways to proactively manage those for users and keep sets of permissions minimized to apps you actively use/want. But none of those really has much to do with whether or not oauth2 is a great way to allow third party access to user resources. That remains a really solid control mechanism.
If anything this is making it safe for the owners because pretty much all the third part apps have full access to vehicle because some owners shared their password to some random third party company so that they can have some additional features on their app.
Probably not a huge risk. Currently third party apps just take your username and password, and log in pretending to be you.
This is a more official and more secure way to do the same - the user/tesla is in full control of which apps have access, what data each app can see, and can revoke access anytime.
I'll take it over the existing situation and over the situation of fully undocumented APIs that others seem to use. I'm afraid there is likely a lot of security by obscurity left in the auto industry.
Automotive software is a regulated space, there's no way the idea of these APIs is developers tinkering with their Tesla for fun (it allows remote execution!) but rather large businesses integrating their apps with Tesla, like Microsoft or OpenAI or something.
Someone could start a business to enable such tinkering. However, that doesn’t seem like a profitable business to be in at all. Potential downsides seem huge, and potential upside seems tiny.
There's some FOSS called TeslaMate that piggy backs on credentials you can steal from your Tesla app. It monitors and records all manner of statistics for whatever purpose you choose. It can also integrate with Home Assistant and all of the wonderful things it can do. The Tesla app shows a tiny amount of information in comparison and none of it is actionable by automations I write.
Wish there was a way to extend voice commands in the car... my own "Alexa skills" but for Tesla so to speak. Even if the only output could be a tweet sized text box.
I would ask questions like... "what streets around here have parking meters" and give me a list to look out for.
Quick glance through the API docs and I'm not seeing it.
CarPlay is irelevant for this use case. You can say Hey Siri/OK Google into the air and just state your request. The phone can connect to the audio system via Bluetooth just like in any other car.
* Press speak button on the steering wheel, speak the query (via car microphone), hear answer via car stereo system with UI response rendered on cars' screen while having the ability to actually control apps on your phone which can then render on car screen.
* Yell at your phone over the car noise and only hear response via audio link and have no ability to control the infotainment system or apps on the phone.
Siri hears me perfectly well in the car without having to yell. The car is rather silent afterall. (Siri is a bad assistant, but that's a separate problem.)
CarPlay would be great but I don't see the relevance to this use case.
What? When you connect your phone to your car over bluetooth it uses the car microphone just like carplay or android auto would use. Why are you yelling at your phone over car noise?
I would love to be able to get the data on my car for making a phone/watch app. Ford has an API but it’s private and they have revoked accounts of people using it.
Too bad. It contains a ton of great stuff, more than their app surfaces.
I’d be quite happy with just read-only access. I bet devs could make some great stuff.
The capabilities of the vehicle_commands section are frighteningly diverse (able to control details of the charging systems, make noises, remotely prevent the car from moving, plug locations into the GPS (unclear if that'll cause autopilot to start moving there).
I guess this means that the remote parts have basically unrestricted access to what they can do to the car that you theoretically own. Fun times.
If you don't like it there is a toggle in the car to turn off remote access entirely. You can leave it off permanently if you want. If that's not enough for you then feel free to also remove the SIM card from the computer.
The charging api end points are also interesting here. I imagine thats it will get more fleshed out for the all the other manufactures in the US to start using the superchargers.
Non related question: there are some examples of good public APIs docs? I would like to develop a product that serves an API but it’s very hard to get a great API as template.
Another SAAS embedded within Car which cannot be opted out. Is there a way to get FOSS Tesla? IMO the Government must intervene to make this opt-in rather than compulsory?
Will it work without Tesla.com account? Or no internet access at all? I just want to drive the Tesla car without internet without any smart features. Is that possible?
Yes, you can drive the car without a Tesla.com account. You miss out on important features such as software updates, remote monitoring/alerting, and the ability to SuperCharge. However you can charge at home or at other Level 2 chargers. And once the NACS plug becomes more widespread you should be able to DC fast charge at non-SuperCharger locations.
You might be interested in https://en.wikipedia.org/wiki/Open-source_car - otherwise, I mean, if you're not into Teslas, no one is making you buy one.. Not sure what your angle is.
I love linux and FOSS myself, not putting your angle down I just don't see your point exactly.
You can vote with your wallets, and everyone else can too.
This is an API for developers to build opt-in apps on top of. The user (the Tesla owner) has to explicitly grant access to an app for it to do anything.
Free trial.
Tesla APIs are temporarily free during this trial period.
Oof.
I wonder if this is one more reason Tesla vehicles have gotten cheaper and cheaper. Elon's probably betting on how much companies would pay for access to APIs and thus user data, and gain income to Tesla on top of simply profit margin on the vehicle itself. Much like he's doing at X. I wouldn't be that surprised to see Tesla data become a major part of X strategy as an "everything app" if he continues that path.
Definitely has me second guessing the trigger I was about to pull on that Model 3 performance that just keeps getting cheaper.
> Elon's probably betting on how much other people would pay for access to APIs and thus user data, and gain income on top of simply profit margin on the vehicle itself.
Tesla doesn't expect end users to use this API. This is meant for fleets (like rental companies).
I feel like you are trying to say that you believe this comment to mean that they might try to sell access to the user data acquired from API usage, but I'm pretty sure the connection "and thus" is equating the APIs with user data, as companies paying for access to these APIs is--similar to having access to Facebook's APIs--giving them access to the user data that is accessible via those APIs.
What I'm trying to say is that this is unrelated to regular folks' cars. For this you need to manually authorize access to your car, and then they can do things like unlock the doors[1]. It's meant for rental agencies and such. Not to scrap data of any Tesla owner (like Twitter Firehose)
Are you trying to say that Tesla will sell bulk user data to advertisers or insurers or credit bureaus or something? That's not what's happening here at all. Users must explicitly authorize each app using this API individually.
That's not at all what I'm implying. I do know how oauth2 works, but charging for API access adds another revenue stream for Tesla that in many other business models is just considered part of the ecosystem attractiveness.
I think it's far more likely that this API is intended to encourage fleet deployments of Teslas and value add from third party apps, rather than for the API fees themselves to be a profit center. That seems far fetched, and I have trouble seeing how that could discourage someone from buying a Tesla anyway, since you can simply choose not to use these features like the vast majority of owners today.
There are real costs to Tesla to run this API, likely primarily the cell bandwidth, so it makes sense to pass those costs on to users instead of subsiding them, which would likely lead to inefficient use of the API or even abuse.
Given that this is named "Fleet API", I'd wager that its pointed at corporations that own a bunch of Teslas for employee use, or for companies looking to start a Tesla based rental car company more than anything.
Not the most important question since it has nothing to do with the fleet developer API.
But yes, if you are fine with not using Superchargers (which would be insane) or the built-in internet then you don't need to deal with the vendor after purchasing the car.
The whole point is that these services could be provided by other service-providers. This is like a car of brand X that only accepts fuel of brand X (except now it is a service like internet or an API).
You can use your own internet connection, the car connects to WiFi.
As for the API, then yes, if you want to buy a fleet of Teslas and manage them with your custom software, you need to go through Tesla. That API is a service and not a product. The car is still a product though.
Given the state of the Twitter API post-Elon, I'd be incredibly unlikely to rely on this unless I have a business contract directly with Tesla with appropriate penalties if my app / access were to be revoked.
It's funny the Elon haters downvote the person saying that the Tesla development is solid yet the parent gets no downvotes and has nothing to prove their statement other than referencing something about Twitter. They are separate companies and APIs. The API used by the Tesla phone app can be used unofficially. I've used it for 5 years, every day. It has been completely reliable for the 5 years I've owned my Tesla.
What’s to “prove”? I don’t have to prove that Twitter turned off its API after Elon bought the company, that’s a fact. I also don’t have to prove he had something to do with it, it was well-reported at the time (admittedly that isn’t quite the same level of fact, but he clearly had the influence necessary and if he didn’t agree with it he could have stopped it from happening). I believe I don’t have to prove that if Elon said Tesla should shut off its API because he didn’t like something someone built, that it would happen. He is the CEO after all.
He’s clearly one of the most impetuous CEOs in the tech industry. If you think that won’t affect people’s decision to partner with the companies he runs, well, you don’t have enough experience with these sorts of deals.
It’s also losing more money than it has since it went public. And it turned off its API because Elon didn’t like it. The latter is what makes it a reasonable comparison.
My own anecdotal contribution, based off the constant bickering of people I know who work for engineering firms that have Tesla as a client, is that they do not have any of their shit organized in a manner which could be remotely described as "together".
There are many words I could use to describe my limited interactions with Tesla manufacturing, but "together" is not one of them.
After being harried to hurry up and build something exactly to the 34th revision of their ever-changing specs (the inside of the electrical panel was powder-coated the wrong manufacturer-original color and therefore unacceptable, and on and on...) and warned about the severe penalties for late delivery and downtime, we got it all finished only to find that they weren't actually ready for it yet. The production floor where it was supposed to go has no room, they haven't gotten permits to even start to pour concrete where it's going to go later...
The one good thing I can say is that at least they paid on time, even though they didn't take delivery yet - better than a lot of "net 30...months" OEMs out there.
That may have been a slight exaggeration. But slow payment is pretty common; we're not particularly bottlenecked by cash flow (rather by engineering) but it's just annoying. "Tricks" in B2B like 1%/10 net 30 only go so far, the norm is that the more powerful companies take advantage of less powerful ones, even when those less powerful tier-1-2-3 suppliers build the equipment and parts that keep their business functional. I guess I don't know why I ever expected anything different.
Should have known all the Tesla masters would dogpile on me defending their SOFTWARE ENGINEERING team.
I’m in no way talking about their manufacturing and assembly teams, strictly software.
Everyone is so hostile towards Tesla, settle down. There’s a ton of ex-meta, apple, uber swe’s at Tesla, they are not some unskilled and unprofessional engineers.
I really miss the old HN community, all anyone does here now is complain and disagree
I don't understand some things, and I'm not going to phrase them as questions but just my opinions.
1) it seems silly to build anything on Teslas platform.
2) it seems silly for customers to add more commercial stuff on top of Teslas platform.
Even as someone who develops software for a living, I think most tech out there today is stupid. Some is useful but most seems not. And occasionally someone shows me use for something I thought was dumb, but I can usually go on without it.
I don't mean to offend, but I think ironically your comment is silly.
If I understand you correctly, you think that there is no value to be added by software to a Tesla.
There are very obvious counter examples. E.g. fleet management for rental cars or 3rd party navigation (in the case of these APIs running on a phone, but using the API for e.g. the current state of charge). There are countless other possible products to be built on top of Teslas platform.
How dare they! I only log in via fax request/response. Although the cookie values have gotten longer and longer -- a pain in the butt to type from the fax reply into my web browser. Any ideas?
These or equivalent APIs have been available and unofficially documented and used by third parties for many, many years. And Tesla has been doing Pwn2Own and bug bounties for a long time.
That said, I think the security implications are fairly important, since I expect one of the exposed features is to be able to unlock or start the car.