API Terms of Service and Storing Data/Editing Transactions

Would an app violate the terms of service if it stores data about transactions in its own database. For instance, the user selects a transaction and applies some data to it that can't be written back to YNAB. Therefore, it has to be stored in its own database, with the transaction id used to pull YNAB data. The application database should not be storing any transaction data other than the ID. I'll even mention in the Privacy Policy that there is some info that is collected in regards to this, and by clicking "Authorize", the user authorizes.

With all these parameters set in place, does this app sound like it would be in good standing with YNAB's API Terms of Service, or would it be in violation of 4? 

Also, does allowing for the editing of transactions, in the same vein as YNAB's interface, within the app constitute a violation of 6?


5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hey there! Thanks for checking in with us about this! Based on what you've described, that functionality sounds entirely within the Terms of Service! As long as you specify which information you're collecting and how it will be stored, and that it won't be passed on to any 3rd parties, that should be fine. I also don't see any issues with allowing users to edit transactions within the app especially if there's app-specific info attached to those transactions. We're big on "good faith" so as long as the app is intended as a supplement to YNAB and not a replacement, you should be good to go. I hope that helps and we're excited to see what you build!

    • Sarah (YNAB Support) So I assume, then, that storing the transactions themselves in the application's database would be more like competition. It would be integrative competition, but the fact that it can store transactions itself would make the possibility of it being a suitable alternative to YNAB for users likely. And if that is the case, you would cancel the API service for it.

    • Sarah (YNAB Support) Let me explain with a real-world example. Mint (from Intuit) can be considered a competitor. It is a budgeting app that stores transactions and shows reports about them to users on its web interface. Currently, it uses Plaid to sync transaction data from financial institutions.

      If Mint wanted to create a feature where users would be allowed to import and sync their YNAB transactions to the user's Mint profile, would you give them access to use your API? Or is Mint's status as a viable alternative for users enough of a reason to deny them?

    • Purple Pegasus Thanks for these follow-up questions! I'm jumping in for the team here with some clarification 👍🏻

      We deny API approval to any integration that could be used to give business to our competitors. So in your example, the reasonable conclusion from a YNAB import to Mint is that the user could stop using YNAB because all their transaction information would now be in Mint. That would not be considered an acceptable use of the API.

      Circling back to your app, if storing YNAB's transaction data is meant to be a supplement to YNAB, in other words, your app wouldn't function if a user isn't using YNAB, that's okay. But if it would be possible to import YNAB transactions to your app and then the user could stop using YNAB altogether in favor of your app, that would be a violation of the Terms.

      Does that help clarify? Let us know if you still have any questions!

      Like 1
    • Rachel A shame. Modular transactions would be an extremely convenient innovation for the industry. But I can understand the concern.

Like Follow
  • 2 mths agoLast active
  • 5Replies
  • 57Views
  • 3 Following