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.

  

  Types of Vehicle Connection
• 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. In Owner 2's use case, multicall3 is highly recommended for better user experience. For general usage of the multicall3 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 of setPrivilege function calls grouped in a single transaction. A general rule of thumb here is to divide your privilege requests up to chunks as the setPrivileges 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 call setPrivileges 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 to 0xA address for a vehicle with a tokenId of 9527, and the requested privilege expires on 1713510000 (unix timestamp in seconds). The caller needs to be the owner of the vehicle with that tokenID.

• 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.

Security & Compliance