by Owen on August 12, 2009
We’ve rolled out modification tracking for three key API types: invoices, payments, and clients. Each of these types now has an updated field. This field is not writeable; FreshBooks will update it, automatically, whenever anyone makes a change, either through the web UI or the API. As with the existing date field, list requests can filter by updated time, using the updated_from and updated_to parameters. For mobile apps or for FreshBooks systems with a lot of invoices, this means that API clients can keep up with changes to invoice data without re-listing every invoice (or payment, or client) in the system periodically.
<request method="invoice.list"> <updated_from>2009-08-10 00:00:00</updated_from> </request>
<response xmlns="http://www.freshbooks.com/api/" status="ok"> <invoices page="1" per_page="25" pages="0" total="0"/> </response>
<request method="invoice.update">
<invoice>
<invoice_id>00000000021</invoice_id>
<discount>20</discount>
</invoice>
</request>
<request method="invoice.list"> <updated_from>2009-08-10 00:00:00</updated_from> </request>
<response xmlns="http://www.freshbooks.com/api/" status="ok">
<invoices page="1" per_page="25" pages="1" total="1">
<invoice>
<invoice_id>00000000021</invoice_id>
<number>0000021</number>
<!-- ... -->
<discount>20</discount>
<!-- ... -->
<updated>2009-08-10 12:53:42</updated>
<lines>
<!-- ... -->
</lines>
</invoice>
</invoices>
</response>
The complete documentation is, as always, in our API docs, under the invoices, payments, and clients sections.
The other types in our API will be retrofitted with updated fields sooner or later. The three that we picked for this release cover most of the cases where API clients request large lists, so we wanted to get this out early, even with only three API types supported, to let people start using it sooner.
If you have any questions or suggestions, leave a comment, send us a note at .(JavaScript must be enabled to view this email address), or drop by our Developers forum.
Enjoy!
Eric Muntz
August 12, 2009
Nice! That’s definitely good stuff, good work API team.
Keith Simmons
August 12, 2009
Great work!
Ivan Vega
August 12, 2009
Definitely useful, however it seems you’re not considering deleted objects as “updated”.
To find out which clients were deleted for example, we have to retrieve *all* of them (more resource intensive now that all the fields are returned on a “list”) and compare those with a cached copy.
Should I post a request on your forums or can you forward this to the developers?
Thanks!
Ivan Vega
August 12, 2009
Also, in what timezone are the options specified/returned?
Dobes
August 12, 2009
Hey, I didn’t know the lists contained all the information now - does that mean I can stop re-fecthing everything in the list after I do a <whatever>.list ?
Dobes
August 12, 2009
Nevermind, I found the other post. I’m guessing the update times will be in Eastern (FreshBooks’ HQ time).
Owen
August 12, 2009
Ivan: more graceful handling of deleted objects is a good idea. We have the data we’d need to do something sensible, but it’s a fairly ugly change to the API semantics. Right now, every object in foo.list is “live” barring bugs, and deleted objects should not appear at all. We’ll have to put some thought into the cleanest way to do that. Still, good idea.
The timezone is basically irrelevant; you should probably only be tracking the most-recently updated time for each type and passing that back in subsequent requests. For what it’s worth, the timezone is actually EST/EDT, but under the hood it’s stored in UTC+0. We’re still hashing back and forth between returning the time in UTC+0 or returning the time in the system’s TZ.
So long as you key your own requests off of the maximum updated time from a previous response, things should just keep working.