Can someone let me know whether Omni offer an open API for development work?
I guess I’m just evaluating whether it would be possible to integrate Omni with other platforms to allow the querying of existing projects/contexts and the creation of new ones.
Thanks very much!
The closest thing to an API is the Applescript commands built into OmniFocus.
Hi Wilson - thanks very much for the reply.
Can the Applescript commands be triggered from outside of the platform? Ideally I’d like another piece of software to be able to query my Focus Projects.
Thanks again for the help!
It would probably have to be Mac based because AppleScript is typically a Mac OS X only feature. I’m not an AppleScript person but perhaps one of the other forum members may know more about this.
If you’re talking about running the scripts from other applications than OmniFocus, then yes. I run them from Hazel or Alfred all the time. To run them on OmniFocus, the script itself has to call out which application to work on. So it doesn’t matter what application runs them.
Back in August, I emailed OmniGroup with this very same question. I got a reply from “Aaron C., Support Human” I’ve pasted below. I wish that OmniGroup would build an open RESTful, JSON API so that I could write 3rd party integrations without the need for hackish scripts or IFTTT. Until such an API is implemented (with good documentationl!), it will remain, IMHO, difficult to continue automate data inputs from 3rd party services.
If you hear rumors of an API, let me know!
While there isn’t currently an open API, there’s a feature request open to make one accessible in the future, so I’ve let the team know you’d like to see this as well. Currently though, OmniFocus does support access through WebDAV, so theoretically you may be able to implement something by crafting XML transactions and uploading then via WebDAV. Here’s a few posts by our CEO, Ken Case, who explains the syncing process on our forums - that may be a good start, but a search of our blog and forum should turn up more.
In the interim, what we recommend for most folks is to create workflows with IFTTT, as you’ve suggested.
there are a couple of Alfred workflows that read the OmniFocus database directly - e.g. http://www.alfredforum.com/topic/1783-omnifocus-task-actions-updated-to-31/ . it’s a sqlite database & the workflow is able to do things OF on the mac can’t do directly, like search the whole database rather than just a single project or view.
In addition, if you don’t mind parsing some XML, you can get access to the whole OmniFocus database at
~/Library/Application Support/OmniFocus/OmniFocus.ofocus. That’s just a folder with a bunch of zipped XML files in it. It’s not 100% easy-to-read, because it’s usually made up of a “base” file, which is then patched by a series of other files.
If you’re good at learning by reading code (and happen to be fluent in ruby :P), you can check out one of my projects here which does just this. The
Fetcher class and its sub-classes deal with the relevant code.
Advantages of accessing the XML directly, rather than going in through Applescript, are that you can always access it (even when OF isn’t running), and you don’t need the Pro liscence. Disadvantages: well, it’s a lot more complicated than just making some Applescript calls…
(Eventually I might even get around to documenting the process!)
@jyr I don’t know any Ruby but I cloned your project and was able to list my basic projects etc. Neat!
I am curious why as to why it is a one-way integration, as I would very much be interested in being able to create tasks under an existing project by calling similar ruby scripts as the one I made to list my projects :D It seems the next logical step with what you have would be two-way integration.
Did you find it technically impossible with your approach? Or just challenging/a lot of work? In any case, thanks for your efforts on this.
You didn’t specify Mac or iOS. If the latter then Omnifocus participates in x-callback-url.
The one gripe I have with it is it doesn’t do update of tasks, for example to adjust the due date.
Hey @Takeington, thanks for the reply! It still feels a little bit like magic when people install stuff I’ve made and it does what it’s supposed to. I guess the pessimist in me just expects stuff to break as soon as it’s taken away from my exact setup.
Regarding two-way sync: at the time of writing, it would have been possible to add items to the XML file that makes up OmniFocus’ database, assuming that you obey the various rules on IDs and the like. I don’t think there’s anything that would stop you adding items and having OmniFocus accept them as its own. However, there were a couple of things that stopped me doing anything in that direction:
- First, things tend to just get more complex as soon as you have two-way sync. I’m sure there’s ten or so points I haven’t considered, that would come up as I added code, that would take me on wild detours as I tried to build in some form of verification or error-checking or what-have-you.
- Second, if things break in rubyfocus as it stands, you end up with a messed-up HTML file. If things break when you’re doing a write to an XML file, you might end up with a corrupted OmniFocus database. And given how a good fraction of the OF userbase probably lives their lives in this thing, that would probably be A Bad Thing to Enable.
Neither of those points make this thing impossible, but it means I’m not keen to do this when it’s basically my spare time I’m pouring into the project. It’s been a while since I’ve really poked around with the innards of RubyFocus - things get in the way, spare time gets eaten up, the normal rigamarole - so I’m not planning on doing anything like this in the future.
(In addition, it seems like OmniGroup is moving toward encrypted databases, which is an excellent choice and very important, given how they give you the choice to store your entire life in the cloud. I’ve had a poke at trying to build a decryption algorithm in ruby, but I quickly found myself getting lost in C libraries, bitwise operations, and the intricacies of the AES protocol. Right now everything’s fine - you can read your local XML file for information just great - but it limits the library in terms of remotely fetching OF data from the cloud or the like.)