Developer FAQ
Frequently asked questions in our developer community
DIMO Basics
What types of vehicle connections are there on the DIMO Network?
We currently support software connections (aka synthetic device) v.s. hardware connections (aka aftermarket device). Software connections include Tesla and Smartcar integrations, while hardware connections include the DIMO Macaron (Hashdog) and the DIMO AutoPi.
What are the differences between each vehicle connection mode?
Check out the connection comparisons here for more information: https://drivedimo.com/pages/comparison
How do I know if a vehicle is supported via software connection on the DIMO Network?
🎉 While all Tesla vehicles are supported, you will need to check https://smartcar.com/product/compatible-vehicles to see if software connection is supported for your vehicle.
API & Integrations
How many APIs are there?
DIMO currently provides many different API builds, with most of them being REST APIs and 1 being a GraphQL API. You can learn more about them in the API References section and the DIMO GraphQL section.
That is a lot of APIs to handle, is there an easier way that I can connect to these APIs?
We understand the APIs are very diverse given the fact that the DIMO Network supports all types of developers. We have a developer SDK to facilitate the build process.
What are the different ways to integrate with DIMO?
As a developer, you can integrate with DIMO using the typical API route where you actively fetch for DIMO's API data, this applies to Hardware Devs, Fullstack Devs, and Data Devs. On the data consumption part, you can also use our Streamr option to stream vehicle data into your application as an alternative to actively polling the APIs.
What are the Streamr options currently available?
DIMO offers a weather stream and vehicle streams.
How do I get API credentials as a Developer?
As a developer, please visit our Discord and reach out to a DIMO team member for developer registration & verification. We have recently completed Developer Licensing and will facilitate the Developer Onboarding process in the near future.
Web3
Do I need to be a Web3 developer?
You don't have to be a Web3 developer to build on the DIMO Network. We use terminologies that are different from the Web2 world, for example "wallets, blockchains and tokens" can simply be translated to "accounts, databases and rewards".
Why is DIMO built on Web3 technologies?
The DIMO Network is built on Web3 technologies to solve many fundamental Web2 issues, we believe if technology is open source and user-owned, people save money and get access to better apps and services. We also pride ourselves in being fully-transparent in our stack of technologies. Learn more about DIMO on the Blockchain here: https://dimo.zone/transparency
Do I need a wallet to be a DIMO developer?
As of February 2024, yes, you do need an Ethereum wallet in order for you authenticate with many of our REST APIs. We are currently working on a solution that may assist with the Developer Licensing so DIMO can assist with the 0x address provisioning.
Data
What is the data volume per month per device on average?
Under the hood, the AutoPi and the Macaron transmits data at a different rate: [AutoPi] Average payload is between 4~8 kb. Average data volume between 100~200MB/month, capped at 500MB/month. [Macaron] Average payload is between 33~69 bytes. Average data volume 1~ MB/month, capped at around 0.015MB for every 4 hour window. For future versions of the Macaron that runs on a 4G LTE network, this cap will be adjusted accordingly.
Development Best Practices
How should one handle multiple transactions?
DIMO strongly recommends using an ABI like multicall3 to handle multiple calls and allow the transactions be bulk-signed together. So instead of handling 100 signing of transactions for 100 vehicle permissions, you should build
multicall3
into your application.Here are the 2 main use cases for
multicall3
:Aggregate results from multiple contract reads into a single JSON-RPC request.
Execute multiple state-changing calls in a single transaction.
As illustrated below, the request for privilege to access
Owner 1
should be straightforward (see orange lines for signing the transaction & granting privilege to your app). However, in the case where an owner has more than one vehicles, they are now forced to sign multiple transactions for the same app. InOwner 2
's use case,multicall3
is highly recommended for better user experience. For general usage of themulticall3
ABI, we suggest checking code examples in their GitHub.DIMO also provides a
setPrivileges
function on the vehicle contract that takes in an array of tuples which invokes a series ofsetPrivilege
function calls grouped in a single transaction. A general rule of thumb here is to divide your privilege requests up to chunks as thesetPrivileges
function is performant up to 100 requests bundled together. So if you have 1,000 vehicles that you are requesting privileges for, divide that batch into 10 chunks and callsetPrivileges
10 times.An example of the input would be
[(9527, 1, 0xA, 1713510000), (9527, 2, 0xA, 1713510000), (9527, 3, 0xA, 1713510000), (9527, 4, 0xA, 1713510000)]
. This input is requesting privileges 1 through 4 to be granted to0xA
address for a vehicle with atokenId
of9527
, and the requested privilege expires on1713510000
(unix timestamp in seconds). The caller needs to be the owner of the vehicle with thattokenID
.
When requesting for the
access_token
to the API, who's wallet should I be using?DIMO recommends using a developer's signer wallet(s) to request for API access. This is a set of wallets that you can rotate around from time to time (see illustration above) as you request for an
access_token
. The signer wallets are added to your Developer License as authorized signers by you (License holder).The authenticated user (via the signer wallet) will be able to access the protected API endpoints, but will NOT automatically have access to the end user's vehicles, which is the intended behavior as part of the DIMO privilege model.
Using the end user's wallet to sign for the
access_token
is generally not recommended.How should an application import a list of vehicles with VIN?
DIMO recommends using
/fromvin
(see Create a Vehicle) to create the vehicle. If the VIN already exist in the DIMO Network, the request will return a 409 as it already exists in DIMO.How should users of my app share their vehicles with my app?
The end users of your application will need to share vehicle permissions via the DIMO Mobile App or through your own implementation of privilege sharing functions - this should be built on the
setPrivilege
function of the DIMO Vehicle Smart Contract.Should my app be storing vehicle information on my database as the source of truth?
The source of truth for vehicles should be coming from the DIMO Network as it has the most updated vehicle information that's associated with the end users' connected sensors or integrations. If you are polling vehicle data once and storing it locally in your database, do add in a check in case vehicles are removed.
The extra check avoids causing discrepancies between your system and the actual state of vehicles.
Community Contributions & Resources
How can I contribute as a developer?
The majority of the DIMO Network is built on open-source software and we're very fond of our developer community. Check our GitHub repositories and join our Discord if you're interested in contributing.
Last updated