Barry Hess

Sorry for the delayed response. If you write into our support team, we’ll look at your specific problems and help you get things sorted. Thanks!

http://www.getharvest.com/help/contact

Definitely possible. Take a look at the Reporting API.

We have decided not to support JSONP in our API at this time. We are not comfortable with the security profile of cross-domain calls. We also don’t see a ton of value in JSONP for an authenticated API like Harvest’s.

Full JSON support is still in place.

That’s right, you’ve been asking for it and it is finally here. In truth, the Harvest API has been JSON accessible (for the most part) for a while now. This morning I made sure everything has JSONP support as appropriate and decided to put out the public word.

Consider this feature beta for the time being and please do write support if you find any issues with it. Documentation is sparse. We’re hopeful those desiring JSON will find the API works about as they would expect. Do let us know if that is not true for you!

Thanks for letting us know. Would you be willing to write in to support and give us some more details so we can clean anything up as necessary. Would be a great help!

http://www.getharvest.com/help/contact

I’ll address your final questions first. If rates change over time, running reports to see the value of work you completed last year at a different rate (for the same project) will not display what you actually invoiced for. The invoice itself is frozen in time. Any reports generated in Harvest are going to use the new rate, however. It’s a trade-off: greatly simplified code that is easier to maintain for some oddities in reporting.

With regard to the inconsistent invoicing by project/person/task hours, I think it would be best to write in to support so we can take a look at the specific example. If there is a bug here, we’d like to fix it. If not, we’d like to clarify how things work for your specific case.

Please write us here and we’ll get you squared away: http://www.getharvest.com/help/contact

There is only one rate that costs are calculated from. If the rate changes the costs will change as well. We don’t take a snapshot of when rates change versus when costs are incurred.

You’re right – time entries can not be marked invoiced/uninvoiced at an item level. Only at a report level.

Hope that clears up any confusion!

rperfect, that shouldn’t have been so! I have updated Harvest so updated_at will behave more sensibly. Unfortunately this won’t update any of the old records created prior. But all client records going forward should be kosher.

Thanks for letting us know about the problem!

Thanks for the feedback, Jim. We definitely have thought about each and every one of these things. We try our best to address what we can with the time we have.

The reason the reporting API is atomic (by project/user) is to protect the health of the Harvest system for everyone using it. If a large account hit a large timeframe for all reporting data a few times it could slow down Harvest performance for everyone. And since large accounts are frequent API users, that potentiality is very real. There are certainly other ways to protect the health of the system, such as more draconian API throttle limits. I suspect the average API customer would not appreciate that technique.

My suggestion if you are going to do a ton of reporting is to sync data to your own local store and report from there. The recent addition of an updated_since filter on the reporting API should help reduce the size of the responses and ease syncing on your side. Looping through a list of projects in itself is a pretty trivial programming problem. You should be able to limit archived projects with the methods described in my previous comment.

Short version: it depends on your account profile, but looping through user reports is probably best.

If you have a ton more projects than people in your account, I think running through the user reporting API with the only_unbilled flag and a time period will be the best route. For most accounts, I think this would be the case. Especially given looping through projects would include inactive projects and I suspect many of those would not have any time entries for the time period you are targeting.

If you have a fair number of archived users, you could also limit the number of users you report on by excluding those with an updated_at timestamp prior to your target time period. Most likely that updated_at timestamp on a user record will be the time the user was archived.

To be more clear, I just made a call using a user_id in our account and it worked. I don’t see the breakage in the reporting API.

Did you actually call this URL as written?

GET /people/#{user_id}/entries?from=YYYYMMDD&to=YYYYMMDD

The #{user_id} portion needs to be replaced with a valid user_id for your account.

Luis, thank you so much for writing in about this. I have found the problem in our JavaScript and will make sure this behavior is consistent with how the rest of the application works. The fix should go out before the end of the week!

Luis,

Sorry about these problems. I will take a look early this week and figure out what is going on.

Yes. All new + changed objects.

Ben, the Reporting API also has an updated_since filter.

http://www.getharvest.com/api/reporting

Tracking time is not really a fundamental change in a project, which is why updated_since does not reflect that activity in the Project API.

The updated_since filter on projects is only meant for the project properties themselves. One corollary to this is that user and task assignment updates to the project will also refresh the updated_at attribute, which will impact results using the updated_since filter.

Hi,

We’re going to need more info to investigate your problem. Please write in to support and we’ll get right back to you:

http://www.getharvest.com/help/contact

If you could include a screenshot, that would be even better!

We have released some new filters throughout the API. The updated_since parameter should make syncing any locally stored data a much easier task. The new filter has been added to the following API’s:

• Reports
• Tasks
• People
• Expenses
• Task Assignment
• User Assignment

The updated_since filter was already available prior in these API’s:

• Projects
• Clients
• Client Contacts
• Invoices

Along with this change, the Reports API now also has a filter available on is_closed.

Please do let us know if you have any questions or concerns with these new API methods.

Good suggestion, Jim. I’ll update that when I get a chance.

http://www.getharvest.com/api#api-authentication

Admins can access all calls. Project managers can see the projects they manage. Basic users can use the Time Tracking API.

The Time Tracking API returns day entries along with a list of assigned projects including the client name for the given project.

Hope that helps!

I checked out the mobile webkit issues on the iPhone, and it was also having some crazy problems. Should be fixed up now.

Thanks again for giving us a heads up!

Thanks for letting us know about this. We’ll take a look.

Sorry for this – we’ll take a look right away.

Thanks for the feedback, folks. We keep seeing more demand for this feature and your feedback definitely helps us prioritize our API work.

Jim, wanted to let you know any new posts or comments should respect Textile formatting just fine. We also have code formatting improved as well. Hope that helps!

Harvest user Jim Kring made us aware that we have never documented the time tracking API feature which allows administrators to make changes to the timesheet on behalf of other users. The documentation is very simple:

http://www.getharvest.com/api/time-tracking#oth…

Basically, add an “of_user” parameter to any time tracking API call for interacting with other users’ timesheets.

Yes, Jim, this feature has been undocumented in the API for a long time. It is time to change that. Here is the quick and easy documentation:

http://www.getharvest.com/api/time-tracking#oth…

(As for the forum formatting issues, I’m going to take a look at that today.)

You are correct. We limit reports API calls to by-project and by-user calls to protect the health of the Harvest app servers. Arbitrary reports across an entire account can be very intensive, especially for larger accounts.

I suggest updating your data with a job once or twice daily rather than making the calls inline with whatever service you are providing.

This is the API documentation you’ll want to reference:

http://www.getharvest.com/api/reporting#get-pro…

Sorry about that forum issue, Jim. We’ll try to get that fixed up. Meanwhile I edited your post so the link is as you intended.

Thanks for all the feedback!

Yes, our number generation logic should handle any invoice number that ends in numerics.

As of last week, the web UI also uses this logic to generate the default number given when you go to create a new invoice. You can change this number if you’d like. We don’t plan to offer an auto-numbering-only option for invoices, but in a practical sense the web UI should work that way today.

In Harvest, our invoices are on a client-by-client basis. While you can limit invoices to project-per-invoice, it’s more of a manual process.

Point being, the invoice number generation will first look for the most recent invoice for the same client and increment the number from there. Then it will look for the most recent invoice on the entire account. Unfortunately it does not attempt to look for the most recent invoice for a single project.

Hope that helps!

Today we have added a feature to the invoices API. When creating a new invoice with no number attribute passed to it, Harvest will auto-generate a unique number for you.

Related: Invoice API documentation

Please let us know if you have any questions about this new feature. Thanks!

It is a little confusing, I agree, but here’s how you get all the projects for the authenticating user. A GET to /daily will provide a list of the projects and tasks available for the user.

http://www.getharvest.com/api/time-tracking#get…

Hope that helps!

Thanks for the vote, Robin.

Thanks for the idea, Anwar. I am going to note this down and we will let you know if we bring our Highrise integration to estimates.

Thanks for sharing your fix here. I agree – hopefully it will help someone in the future!

Tom, I’ve gotten the field fixed up. Is billed is a (relatively) new field and I believe it has been wrong since it was added. Hope that helps!

Sorry about the code posting. You may use Textile helpers to paste code. This means PRE tags for code blocks and ‘@’ symbols around inline code. We should document this, as well as style the code blocks.

I do not think the is-billed type was changed intentionally. I’ll take a closer look today and see what’s up.

Yes, we do plan to add estimates to the API at some point. I will add your name to the list of those desiring it. Thanks for the feedback!

@fhwang Wanted to let you know this thread has been a hot topic of discussion with our dev team. We are going to discuss our options next week. We’ll start thinking about the best way forward for Harvest’s API.

Thanks for the great feedback!

If you know the invoice_id (from an API sense, not the Harvest user interface sense), starting a PDF download should be pretty simple. The URL format is clear:

somesubdomain.harvestapp.com/invoices/#{invoice_id}.pdf

This URL is not guaranteed to stick around in quite the way that our documented API would be, but for the time being it should work.

This new request. Are you asking for an API method to fetch all projects assigned to a user as well as all projects assigned to a task? Basically, the inverse of these?

http://www.getharvest.com/api/user_assignment
http://www.getharvest.com/api/task_assignment

@fjeldstad Long-running reports are the single biggest threat to the performance of harvestapp.com. The API atomizes report calls for this reason, as exposing open-ended timeframe reports over all projects in an account to an automated call via API would be very risky.

If you would like to hit every project in your account to do a report visualization you will need to handle the throttle limit. Sorry that we are not able to provide a more convenient technique to get this data. The health of our servers is of top priority here at Harvest.

Hope that helps!

Thanks for the feedback. Is your use case to sync latest updates?

Thanks for this request, Jim. Paging in these areas make sense (especially projects) and we will consider it in our priority list.

Note, there is a new updated_since parameter available which may help you in the meantime:

http://www.getharvest.com/api/projects
http://www.getharvest.com/api/clients

Thanks, Jim. I’ve added this to the ticket and we’ll consider it when it comes time to implement.

Marked this one down as well!

Marked it down, Jim!

Jim,

Sorry, but we do not have an API method to do timesheet approval at this time.

Sorry, Jim, but at this time we do not offer a way to filter invoices by purchase order via the API. You will need to pull down all invoices and filter them on your side.

Hi, Jim. Unfortunately we do not have a way to get the invoice defaults via the API. We probably should, though. I will put this on our future enhancement list.

Happy to help!

Brent,

Our client API documentation is here:

http://www.getharvest.com/api/clients

I’m not sure if Salesforce will allow you to fire the necessary POST request to the Harvest API, however.

You may wish to contact Joe Ferraro of Mavens Consulting because they are running beta tests on a native Salesforce integration with Harvest.

http://twitter.com/joeferraro/status/21493918751

Hope that helps!

~Barry

Generally speaking, only the time tracking API is available to basic Harvest users:

http://www.getharvest.com/api/time_tracking

From the API docs:

Generally admins can access all, regular users can see their own Timesheet and PMs the projects they manage. You can use a regular account for the Timetracking API, but to interact with the Extended REST API it is recommended to have a special user with admin role.

There is a new filtering option available in the invoices API. For the SHOW ALL requests, you may now pass an updated_since parameter. This allows easy access to retrieve only the most recent changes for the invoices you are going after.

http://www.getharvest.com/api/invoice

This addition is along the same lines as our previous clients and projects API update.

There is a new filtering option available on the clients, client contacts and projects API. For the SHOW ALL requests, you may now pass an updated_since parameter. This allows easy access to retrieve only the most recent changes for the resources you are going after.

Example:

Say I keep a list of client information in an internal database. Currently this is updated nightly via the Harvest API. To update the internal database, the job must pull all clients from Harvest and update the internal DB accordingly. This could be done either by comparison for changes or just with a dumb overwrite of all data.

Now with updated_since in the client API, the job can simply call the Harvest API with the time of the previous job execution. Harvest will return only clients that have been updated since that time.

Documentation is available on the respective API pages.

http://www.getharvest.com/api/clients
http://www.getharvest.com/api/client_contacts
http://www.getharvest.com/api/projects

Please let us know if you have any questions!

@jonathanb You could certainly give a try at writing a script against our time tracking API Just grab the appropriate entries, change the task ID, and save each of them.

Would that work for you?

We have not heard of any Rainmeter integrations in process – would love to see what you and others can come up with!

Duly noted. Thanks for providing more details!

@dragulescu Thanks for the thoughts. I don’t believe that is a real good fit for Harvest as we are mostly focused on time tracking and invoicing. But we’ll definitely make a mental note of your idea!

@John I’m not quite following your request. Harvest is designed to use rates to calculate invoice totals, not the other way around.

Thanks for this feedback. We agree that we could improve this. I notice it most when trying to browse the list of pages available via my back button!

Thank you so much for the feedback. I’m going to document these ideas here. File upload is particularly an in-demand feature for Co-op.

After creating the client, you will get the location to find the client in the Location header. It will look like this:

/clients/#{new_client_id}

A GET to that resource will get you the client information. Hope that helps!

Chris, thanks for the post. While we’ve had developers contact us about Jira integrations they are working on in the past, we have not heard of any publicly available integrations. We’d love to hear more about whatever you come up with!

Thanks for the request, Jim. We understand your concern and we do have this on our list of potential improvements to Co-op.