It would be nice if Quicken had a "developer" API like QuickBooks does for reading and writing data

Quicken Community

With such an API Quicken Inc could leverage external programmer's time to make Quicken better.

UKR

I second that motion.
Up until about the year 2005, an API was available which would allow the use of Quicken on early PDA devices by a program called Pocket Quicken.

An application programmers' interface would make it possible for programmers to, for example, develop versions of the Quicken Mobile app for as yet unsupported smartphone and tablet device types.
Or maybe someone could figure out a method for recovering broken-beyond-repair Quicken data files on both Windows and Mac systems.

Rick Gumpertz

More importantly, it would allow programmers to provide new reports that Quicken hasn't got around to (or are of limited interest)!

It might also allow programmers to help out Quicken by adding things like reliably moving data from Quicken for Mac to Quicken for Windows...

I wish I could add add hundreds or thousands of votes to this idea!  Please add your vote.

q_lurker

Doesn't such an interface require that the inner structure of the QDF database become 'public'?  I have always understood that was the line that Intuit / Quicken, Inc. would not cross, if only because it then opens up more portability from Quicken to 'other' software.  Just asking.  

Unknown

q.lurker said:

Doesn't such an interface require that the inner structure of the QDF database become 'public'?  I have always understood that was the line that Intuit / Quicken, Inc. would not cross, if only because it then opens up more portability from Quicken to 'other' software.  Just asking.  

No, it doesn't require the structure of the QDF database to become "public"/known.

In fact just the opposite.  And API sets a "known standard interface" or "abstraction" of the actual interface.

For example, Windows has a "mouse" API.  The programer doesn't have to be aware of the fact that one user has a mouse, another a trackball, and yet another using a trackpad.  Instead it has an "abstracted interface" that gives it the information needed in a general way.

Another example using Quicken.  You export the register as CSV file.  You have no idea of how the those transactions are actually stored in the database.  You just know that the fields will be separated by comas, and the transactions by line.

Unknown

q.lurker said:

Doesn't such an interface require that the inner structure of the QDF database become 'public'?  I have always understood that was the line that Intuit / Quicken, Inc. would not cross, if only because it then opens up more portability from Quicken to 'other' software.  Just asking.  

But since since you have brought up "other software", I might as well lay out what I really believe.

This was a "pie in the sky" request.  The only real reason I submitted it is because of the one submitted that requested dumping of all of Quicken's data to a text format, and the ability to read it back in.

If such an API was created, that would be one of the things that it could be used for. But it could be used for much more, and as such would benefit a lot more users than one that only highly skilled people could make use of (fixing problems in a text dump of data is no easy task.).

But I don't think they will do either.  There is a lot of work involved, but also it would make it easy for other companies to write software to bring Quicken data into their programs.  And Quicken Inc would most likely see that as a threat to their hold on their customers.

Rick Gumpertz

Appropriate Non-Disclosure Agreements could go a long way toward protecting Quicken Inc.

Furthermore, I suspect Quicken has far more to gain by allowing add-ons than they would lose by allowing other software to copy old data.  Copying old data is just a one-time operation used by customers that Quicken has already lost.  (The content of those data really belong to to the customer anyway!)  On the other hand, gaining a collection of useful add-ons that work (only?) with Quicken would reinforce Quicken's dominance!

Unknown

Rick Gumpertz said:

Appropriate Non-Disclosure Agreements could go a long way toward protecting Quicken Inc.

Furthermore, I suspect Quicken has far more to gain by allowing add-ons than they would lose by allowing other software to copy old data.  Copying old data is just a one-time operation used by customers that Quicken has already lost.  (The content of those data really belong to to the customer anyway!)  On the other hand, gaining a collection of useful add-ons that work (only?) with Quicken would reinforce Quicken's dominance!

I agree with you Rick.  Quicken Inc has more to gain, by doing it.  But of course it really depends on how worried they are about it, on if it will affect their decision or not.

And it is even a double edge sword.  The same interface could make it easier to get data into Quicken from a competitor.

I do know that Intuit and Microsoft where in this "battle" of "make it hard to change", but frankly I don't see any real big competitor to Quicken any more and really think the benefits would outweigh the negatives.

Rick Gumpertz

Rick Gumpertz said:

Appropriate Non-Disclosure Agreements could go a long way toward protecting Quicken Inc.

Furthermore, I suspect Quicken has far more to gain by allowing add-ons than they would lose by allowing other software to copy old data.  Copying old data is just a one-time operation used by customers that Quicken has already lost.  (The content of those data really belong to to the customer anyway!)  On the other hand, gaining a collection of useful add-ons that work (only?) with Quicken would reinforce Quicken's dominance!

How is this a double edge sword?  "The same interface could make it easier to get data into Quicken from a competitor." implies that the customer owns and uses  a copy of Quicken and so Quicken is getting its money...

Rick Gumpertz

Rick Gumpertz said:

Appropriate Non-Disclosure Agreements could go a long way toward protecting Quicken Inc.

Furthermore, I suspect Quicken has far more to gain by allowing add-ons than they would lose by allowing other software to copy old data.  Copying old data is just a one-time operation used by customers that Quicken has already lost.  (The content of those data really belong to to the customer anyway!)  On the other hand, gaining a collection of useful add-ons that work (only?) with Quicken would reinforce Quicken's dominance!

BTW, If they are worried about getting data into Quicken, they could define a read-only API!

Unknown

Rick Gumpertz said:

Appropriate Non-Disclosure Agreements could go a long way toward protecting Quicken Inc.

Furthermore, I suspect Quicken has far more to gain by allowing add-ons than they would lose by allowing other software to copy old data.  Copying old data is just a one-time operation used by customers that Quicken has already lost.  (The content of those data really belong to to the customer anyway!)  On the other hand, gaining a collection of useful add-ons that work (only?) with Quicken would reinforce Quicken's dominance!

A double edge sword "cuts both ways".

The point is that it can be positive for Quicken Inc, not just negative.

One edge/direction is Quicken competitors using to make it easier to go to their program (negative for Quicken Inc, positive for them).

The other direction means that people can take whatever format the competitor uses for exporting data, and create a program to convert it/import it into Quicken, taking customers from the competitor (positive for Quicken Inc, negative for the competitor)

And I REALLY hope they don't do:
"BTW, If they are worried about getting data into Quicken, they could define a read-only API!"

Some of the most beneficial things you can do with such an interface would be for getting data into Quicken.  For instance repairing corrupted data files isn't possible.

Rick Gumpertz

Rick Gumpertz said:

Appropriate Non-Disclosure Agreements could go a long way toward protecting Quicken Inc.

Furthermore, I suspect Quicken has far more to gain by allowing add-ons than they would lose by allowing other software to copy old data.  Copying old data is just a one-time operation used by customers that Quicken has already lost.  (The content of those data really belong to to the customer anyway!)  On the other hand, gaining a collection of useful add-ons that work (only?) with Quicken would reinforce Quicken's dominance!

I agree that read-write would be MUCH better than read-only, but the latter is also much better than no API at all.

Perry Smith

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Unknown

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Note I was talking above about Quicken Windows, which uses a very old propriety database format.  So it is quite a different story than Quicken Mac which as you pointed out is sqlite.

But even so I think the request is more about having a standardized API so that people aren't "hacking" the database.  If you are going directly to the database that format can change at any time, and mess up whatever tools you have created.

With an API they can hide such details.

Perry Smith

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Yes.  I agree.  Most of the replies are about Quicken's intellectual property concerns and I was trying to point out that, to me, those are not valid reasons to not create the API.

An official API is always very nice to have.

I came to this thread because I was going to suggest that Quicken should allow third party add ons.  They could have a "store" for such things.

But I didn't create that suggestion because an API is a pre-requisite.  Having "official approved" third party add-ons and even a "Store" would imply that the add-on has been reviewed and it would also provide a simpler method of adding the add-on.

David Severski

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Getting to a sqlite format on the Windows side would allow me to get data out of Quicken for analysis and reporting that Quicken proper looks like it will not support anytime in the near future. While I'd love an API as well, just getting an open and queryable (read-only) DB would be amazing.

Connie Brown

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Sounds like useful ideas.

Perry Smith

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Hi David,

What follows is a pretty ugly suggestion and I've not done it so... it may not work.

VMWare allows you to have a Mac as virtual machine (at least on a Mac it does but I'm believe you can have a Mac VM on a Windows platform as well).  It use to be that Quicken would convert from PC to Mac and from Mac to PC.  Combining those two:

Get a copy of VMWare, create a Mac virtual machine.
Get a Mac copy of Quicken, import your PC data.
Do your queries.

You would need to do at least the import each time you want to do your reports but there are tools that can semi-automate these types of processes.

Are you are the file is not an SQLite DB file?  I'm not a Windows person so I know very little of how to poke at it.  On Mac / Unix, there is a utility called "file" which tells you what type a file is.  Is there such a critter for Windows?  I bet there is, somewhere.

It just seems weird to pay the upkeep for a proprietary DB engine and use it for only one platform and not the other.

Good luck!

Simpler idea... get the cheapest Mac you can find on eBay and squirt your data over to it.  (That still assumes that Quicken will convert from PC format to Mac format).

jacobs

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

While I understand the value of an API and third-party add-ons, I just doubt that Quicken would open things up to do that -- because ultimately customers would blame them/require support from them if anything goes wrong. Considering how much customers blame them for issues out of their control already, I just can't imagine them opening this door and making their support job that much harder.

To have an API, they'd also have to commit to not changing things that would break the API for long periods of time, which could complicate their path to adding new features or fixing bugs. Quicken Mac has had a bunch of database updates over each of the past few years as they work to build out functionality and improve performance. and it's likely that things in the code like record locking might need to be overhauled because it was never created with a possibility of some other process outside acting on the data. 

And to open the door to third-party developers, it could also restrict features they have plans to develop. If a developer builds a widget and sells it for $10, and then Quicken adds the same feature, the developer is going to be unhappy, as are the users who paid for the now-free feature. If Quicken adds a long-requested feature, but after a third-party builds the functionality, they could face legal action by the third-party for copying-and-pasting the third-party's work. This would only work if they carved out areas they're sure they don't plan to tackle so developers could freely dive in.

Again, I understand the appeal of an API and add-ons, but I'm just pointing out that there are lots of factors involved.

Unknown

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

But just imagine...outside developers that could add a Tax Planner, Retirement Planner and even a report engine to the Mac version. Maybe even a Business add on with payroll support. 

Having outside developers do what apparently the Quicken development and programming team is unable to do.  Sounds like a great idea.  

Without having to wait ten or twenty years for Quicken to "maybe" do it. 

This product could be so much more.  I'm really sad it isn't at this time. 

Oh well, I can dream.  

jacobs

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Quicken's move to subscription pricing actually increases the pressure on them to add functionality customers find useful. In a statement when Quicken made that switch last year, CEO Eric Dunn said, "our business success is dependent on our Quicken Members seeing enough value so that they keep their membership."

So why would they make it easy for users to pay someone else for functionality that Quicken itself could deliver? Heck, a third-party with access to the database could provide an alternate way of importing data, such that users could forego their subscription payment to Quicken. (Yes, there are ways they could possibly prevent that, by building a close "store" model wherein they review and approve every extension -- but why put the time and money into building that infrastructure instead of just improving the product themselves?)

smayer97

Perry Smith said:

Folks...

On the Mac, what the Finder calls the data file lives somewhere like /Users/XXXX/Library/Application Support/Quicken/Documents/XXXX's Finances.quicken. This is actually a directory.  In that directory is a file called data which ... you guessed it, is most of your data (sans attachments and other things).  data is just an SQLite 3.0 database so its hard to imagine Quicken has much IP that could be / needs to be protected.

Quickbooks (under Intuit) made the same mistake perhaps a decade ago which I thought was a huge mistake.  Sure... they don't need to keep up a database but the down side is their crown jewels are very much exposed.

If you want to see for yourself... copy that file somewhere else like your desktop.  Drop into Terminal and do:

sqlite3 ./data
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .output foo.txt
sqlite> .dump
sqlite> .exit

And now foo.txt is all of your data in flat text format.  It is in a form where you can insert it back into (recreate) the database but you get the basic idea.  e.g. if you know SQL, you can write queries and pick out what you want.

So... given all that, I would say that Quicken has very little to lose by making a nice API.  With just a little prompting, third parties could probably create a library that tidied up the raw SQL interface a bit but really... you have what you need.  At least, most of it.

Perry Smith A VM emulates hardware (in layman's terms)...so I would expect you would run into all the issues of building a hackintosh trying to install macOS in a VM on a non-Apple Intel PC. Also keep in mind licensing issues... macOS is only licensed to run on Mac hardware. But the installation most likely can be done.

(If you find this reply helpful, please be sure to click "Like", so others will know, thanks.)