Your browser is no longer supported! Please upgrade your web browser now.
Code posts:

Join Us on GitHub for All of Your API Needs

We’ve moved our API documentation to GitHub, and we’ve added some other goodies there as well. Why move it there, you ask? A lot of our developer community is already using GitHub, and in fact, we have several open source projects there ourselves. You can now watch our API (and therefore, get updates when changes are made), ask questions, or contribute to our documentation by submitting pull requests, all straight from GitHub.

We’re also started a wiki called Community Creations and Hacks, where you can look to see what others have already made, or add your own, to share with the Harvest community. This section is for the interesting and useful things that people have built with the Harvest API, and may have very specific use cases, or broader applications. There are already over 20 creations by inventive Harvest users just like you, who dipped into our API and shared what they made. For example, Klokan Tech built an integration between Harvest and GitHub Issues Tracker, and Zach Hobson devised command-line Harvest time tracking. All you need is a (free) GitHub account to access everything you need to know about our API, improve or adapt others’ creations, and even add your own creation to the growing list on the wiki.

Inspired by what others have made, or have an idea you’ve been meaning to make a reality? Roll up your sleeves, and build your own integrations with our API. Have fun, and let us know what you’ve made – we’re happy to spread the love!

Supporting Harvest: Tools of the Trade

I had the opportunity to speak at the fabulous UserConf NYC a few months ago, about how Harvest dropped its support response times. I then followed up with a guest appearance on Supportops Podcast with Chase Clemons from 37signals, where we talked about remote working, Hurricane Sandy, and a some of the tools we use in Harvest support that help to speed up the process. Here’s a quick look at a couple of the tools that I use everyday. Continue reading…

The Harvest Platform: Bring Time Tracking Into Your Application

Today, we’re excited to give developers an easy way to add a seamless time tracking experience right into their applications. Introducing the Harvest Platform.

Traditionally, integrations between applications have required tedious API calls and database changes. With the new Harvest Platform, adding time tracking to a project management, issue tracking or task management application is as easy as embedding a few lines of JavaScript and HTML. Developers can now focus on the core functionality of their apps while easily harnessing Harvest for time tracking, reporting and invoicing.


Over the last 6 years of building Harvest, we’ve received countless requests to integrate with various applications. The reason is simple: users want to simplify their daily workflows. Our customers use Harvest in conjunction with project management or issue tracking applications and they crave a tight integration between the apps.

For the application developers, many are reluctant to add time tracking on top of their product’s core focus. They know that time tracking is just scratching the surface of the true customer need. Once time is captured, customers need to run reports and send invoices based on that time.

With these reasons in mind, we’ve created the Harvest Platform. It’s an extremely easy way for developers to enable time tracking in their application while offloading time tracking, reporting and invoicing to Harvest.

A first-class user experience

To see the type of experience the platform can enable, take a look at the first application to take advantage of the platform: Do by Salesforce. Do is a social productivity tool that helps people work together on shared tasks and projects.

Using the Harvest Platform, the Do team has enabled time tracking by including a timer button with each Do task. When you click the button, the Harvest Platform modal window opens, and it already knows about the Do project and task details and the user simply enters any additional notes and tracks time. The user never needs to leave the Do application for time tracking. shown here using the Harvest Platform integration to bring time tracking to their tasks. If you wish to request early access to this integration on Do, simply create a Do account (if you don’t have one already) and email the Do team

Implementation in 15 minutes

As developers know, integrations between applications can often be a cumbersome development effort. With the Harvest Platform, we worked hard to make sure it’s incredibly easy to use for any developer. Implementation involves only adding JavaScript and HTML to your code. There are no APIs or data models to worry about.

If you’re a developer, head to the Harvest Platform page to learn more. If you have a favorite application which you wish had time tracking, let them know about this new effortless way to add time tracking right into their application.

Harvest’s New PDF Engine

Update: We’ve now added a Snail-mail Friendly option to move the client address to the left for the envelope window. You can find this option, hide columns, and company logo in a new Appearance tab on the Invoices and Estimates configure pages.

Today we’re announcing a significant upgrade to our invoicing and estimate platforms: a new rendering engine for the PDFs you send to your clients.

The new engine, which is built with wkhtmltopdf and Liquid-based templates, renders PDFs based on HTML and CSS. This is really exciting, because it allows us to use more flexible and simple code to create them. This means we can have the exact same code for invoice and estimate PDFs as we have in the app, which means they now have the same design and options.

What’s New

Implementing this allowed us to make some other features available on Invoices and Estimates:

  • PDFs now have the page number at the bottom (and an option to translate).
  • You can now hide the type, quantity, and/or unit prices columns.
  • If you have a company logo uploaded, but still want your invoice to say “Invoice” on the page, you now have this option. You can turn it on where you uploaded your company logo in the configure section, and then change the title in translations (i.e. – you’d rather have “Tax Invoice”). The same applies for estimates.
  • We’ve added quick access to your Web Invoices and Web Estimates.
  • The new PDF engine is also able to render many more languages. See an example of some languages below:

The biggest win is that we now have the flexibility we need for adding features to our invoices and estimates in the future. Any change will automatically work in the app and as a PDF.

We hope this new PDF engine makes your Harvest experience even better.

How Harvest Is Made, Part Two

Last week I wrote about how developers at Harvest deploy code and own the responsibility of keeping our software quality high. Today I’ll touch on the tools and process we currently use to collaborate, stay in touch with customers and glean feedback from our infrastructure.

Developer collaboration

Harvest developers are seldom in the same building, let alone the same state or country. We work as a distributed team, yet we collaborate extensively. All of our code is hosted with GitHub, which makes this collaboration simple. For those familiar with Git:

  • Developers work in feature branches off the master branch, and master is always assumed to be deployable by anybody at any time.
  • Developers use GitHub Pull Requests all the time, and significant deployments are peer reviewed in this way prior to deployment.
  • Continuous Integration server constantly tests our code, and reports concerns to the team.
  • Development takes place locally, but we have multiple production-similar staging environments for testing and QA.

Infrastructure collaboration

We strive to have no ‘walls’ over which features or releases are thrown between team members. We share the responsibility of creating and supporting our software. As the ‘systems guy’ at Harvest, it’s important to me that every developer has the ability to manage systems configuration. It’s also important that if problems arise, the team who responds to these problems is not a siloed operations team, but includes the developers who wrote the code which is running in production.

To this end, we use Chef to transform our systems configuration into a collaborative effort. Every component of our infrastructure is controlled by Chef. This means that technical team members can view and modify production configuration and roll out systems changes. The beauty of Chef is that everything is protected by Git version control and enhanced by the power of Ruby.
Continue reading…

How Harvest Is Made

You may not realize it, but almost every day there are improvements being made to Harvest while our customers are using it. Transparency is a core value here at Harvest, and I’d like to take you through a little of how we work behind the scenes, in a series of slightly technical posts.

The new Harvest Status page

We’ve just released the beta version of a tool we will be using to promote transparency between Harvest operations and our customers: the new Harvest Status Page. Bookmark this tool to keep track of how Harvest is performing at any time.

Balancing priorities

I’ll briefly walk you through the software release process we follow, and in a subsequent post I’ll talk in more detail about the tools and methods we use. If you are familiar with DevOps and the concept of continuous deployment you’ll recognize these in our workflow.

Context determines your opinion on software deployment. Our customers naturally prioritize software stability and the addition of new features as quickly as possible. Customer acquisition, avoiding outages, using cool new technology, and striving for elegant robust code are a few other priorities held by my Harvest coworkers. A natural tension can exist between these priorities. How does Harvest balance this and retain our core focus on a good customer experience?

The simplest answer is: We take small steps quickly through collaboration.

Release cycle and deployments

What may be of most interest to customers is how we deploy new code to Harvest. Harvest changes almost every day, usually multiple times per day. In the time it took me to write this blog post, two different developers deployed five production releases of Harvest. Some might be concerned that a process like this promotes poor quality software. In reality, like many other companies, we have found that this iterative, constant change promotes high quality software, exposes and resolves unexpected issues quickly and allows a distributed team to work on different features concurrently. This means, in a nutshell, that when developers deem code ready to go to production, it goes to production. No artificial release schedule governs Harvest software rollout. There is also no manager whose job it is to ensure our software quality because that is the common responsibility of every person committing code at Harvest.

100% bug-free software is an unrealistic goal, but we strive for a bare minimum of issues by having structure in place to address problems quickly and efficiently:

  • All significant code changes are peer reviewed before deployment. In the next post, I’ll talk about how we do this.
  • Every developer, designer and sysadmin at Harvest is able to (and does) deploy production code.
  • Mondays tend to be the busiest traffic day of the week at Harvest, so we rarely release big new features on Mondays. Same goes for late on Fridays, when bugs could linger over a weekend.
  • We have an internal QA process and production-similar staging environments, where we perform extensive testing when required.

Some deployments warrant special care, such as releases which involve database migrations changing large datasets. Certain database operations could produce a poor customer experience while deployments roll out. We have in the past, and will continue to deploy these releases at times of lowest customer impact, although Harvest’s global customer base reduces this window constantly. We have a maintenance mode which we can employ to take Harvest offline briefly if we need to.

If you have seen Harvest in maintenance mode and we didn’t notify you, our customer, prior to this deployment, we made a mistake and you can be sure that the team is working on the problem with urgency. It happens, but we think Harvest’s uptime speaks to how infrequently this occurs.

Obviously, when it comes to software which has a third party review process, or runs on customer desktops, such as our iPhone App and the upcoming Mac App, our process to roll out change is a little different to the core Harvest software that runs on our own servers.

If this post was too technical (or not technical enough), the one thing I hope you will take away from this is: Harvest software changes all the time in small increments. This concept of continuous deployment isn’t new or revolutionary and it may not work well for every company, but it allows us to strike a balance between stability and agility and keep forward momentum as we build a fairly complex suite of software.

Next week I’ll touch on the tools we use to review code, communicate as a team and keep on top of our infrastructure performance. If there is something you’d like me to specifically discuss, let me know in the comments or directly at

OAuth 2.0 for the Harvest API, Plus a New SDK

At Harvest, we have a ton of pride in our smart and creative users. The ideas you bring to life on top of our Harvest API are always surprising and inspiring. OAuth 2.0 and our new JavaScript SDK are two great tools coming into beta today, and we can’t wait to see what you do with them!

OAuth 2.0 is an industry standard for API authorization, used by Facebook, Google and others. With OAuth 2.0 you won’t need to store the passwords of Harvest users to build an integration. That means more security for Harvest users, and less liability for integration authors. You can learn more about the specifics of OAuth 2.0 and our implementation in the updated API authentication docs.

Our new JavaScript SDK is inspired by the ease of using Facebook Connect. Build integrations in pure client-side JavaScript, without thinking about Cross-domain requests and the details of OAuth 2.0. We’re already using it to add timers to our bug tracking and support tools. It’s a great way to bring Harvest to your other web apps.

  • Add timers to your bug tracking software in only HTML and JavaScript.
  • Import open invoice amounts from Harvest without using server-side programming.
  • Pull reporting into JavaScript to generate custom visualizations and charts.

Again, the best place to learn more is our new JavaScript SDK documentation.

Getting Started

If you’re a user or partner interested in working with our new API authentication and SDK options, make a request for OAuth credentials on this form, or drop us a line at for more information. While in beta, we’re going to issue credentials manually, and that form is the quickest way to get set up. you can sign up for OAuth credentials right from within your account. Go to Manage > Account Settings and click the OAuth2 Tokens button to get started. If you’re not a code-slingin’ type of person, just know that we’re giving developers the best tools available for the next generation of Harvest integrations.

Your comments and feedback about these API additions are important – please do get in touch!

Chosen, a Select Box Enhancement Plug-in for jQuery and Prototype

In May, we released our improved detailed time reports, which included an improved interface for filtering the data included in your report. The filters are such a significant improvement over regular HTML select boxes that we’ve decided to share their code with the world. Today, we’re releasing them as a plug-in we’re calling Chosen (available for jQuery and Prototype).

When building an HTML form, select boxes are often used to present a long list of options because they don’t take up a lot of space. Once a select element includes more than a handful of options, however, they become difficult for a user to navigate. Typing into a field doesn’t always work in an expected way (and many users aren’t even aware of this option) and scrolling through dozens or hundreds of choices is slow and tedious. These problems are especially magnified when the order of options isn’t immediately clear.

Chosen aims to improve select boxes by adding search-based filtering. When a user clicks into a Chosen element, their cursor is placed in a search field. As the user types, options that don’t match the search terms are hidden, leaving only useful results behind. Users can select their choice just the same as a standard select element – highlight and click with the mouse or use the keyboard to navigate choices (up and down arrows change the highlight and enter selects).

Additionally, multiple select elements get an improved interface for displaying selected options. User-selected options are displayed as boxes at the top of the element and are always visible. They can be removed with a single click or using backspace.

Continue reading…

Harvest API: Your Data in Action

Recently Chris Wilson from Search Mojo has been writing to us with questions about the Harvest API. Through the pleasant conversations surrounding Chris’s questions, we learned that Search Mojo was using the API to create an inspiring dashboard. Here’s how Chris describes it:

We created a profitability dashboard to total up which of our clients we are profitable on based on hours, hourly rates and expenses over quarter and month ranges. We then created a score based on that. Your API tool supplied everything and it’s officially up and running on the tvs in the office.

Continue reading…

Thebes: A New, Minimal Sphinx Gem for Rails

Recently, we’ve been sharing a lot of technical lessons from building our new Help Center and in upgrading Harvest to Rails 3. The gem Harvest is releasing today, Thebes, is at the intersection of both projects.

Thebes is a wrapper around Sphinx, the search engine we use on most of our projects. Thebes differs from other solutions by staying as far away from your Rails code as possible. Instead of hiding the Sphinx configuration file behind a domain-specific language, this library assumes you will write Sphinx config files by hand. In Thebes, you edit an ERB template of your Sphinx configuration and populate it with variables at generation time. For developers needing the most flexible or fastest solution possible, this is a great way to work with Sphinx.
Continue reading…