Loading Profile...
EMPLOYEE
Sifter API
Will there be an API?
31
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has this in progress.
The best points from the company
-
We're working on it, but it's not going to be here in a matter of weeks. In general, I would advise anyone who is unhappy with any product not to use it. Naturally, we hate to see people go, but I'd sincerely rather that people be happy, even if it means that Sifter isn't the right product for them.
The last few months have been incredibly busy for me personally, and the reality is that Sifter can't support me full-time. It's getting closer, but it's not there yet. So sometimes, the bills have to be paid.
We've been working on making some important changes to make sure that the we can spend a more consistent amount of time on Sifter. Unfortunately, it's a significant transition, and it takes time. It's not as if we said we were working on the API and then released dozens of other features instead. We simply haven't had the development hours to spend on it. That's changing, but it takes time.
We are investing all of our development time on the API. In order to do it well, and have a clean RESTful implementation, we're also going to make some other changes to the interface to help simplify and tie everything together neatly. That also takes time.
We could rush something out the door, but we wouldn't be happy with it, and neither would anyone else. I'm sincerely sorry that our rate of development is fast enough for your expectations. We're not very happy with how long it's taken either, but we want to do this the way that we feel is right.
We're working on it. If you need it immediately, then I'm sorry, but we're going to disappoint you. I assure you that we're trying to make the best long-term decisions for the application and for our customers. We believe that focusing on speed of delivery is a mistake, and we're not ever going to do that.
I’m optimistic
The company and 1 other person think
this is one of the best points
-
We've officially started on it. There's no ETA, but it's receiving 100% of our attention until it's ready. It will be RESTful and use Oauth. Naturally, we'll post here when it's ready.
I’m excited
The company thinks
this is one of the best points
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?We definitely plan on including a well-documented API, but it's possible that it won't make it into the initial release. It's definitely a high priority, but the web and email interfaces are more important to get right for the initial release.
-
Inappropriate?Once an API is established, integration with Github would be super-helpful.
2 people think
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
Totally agreed, integration with source control (GitHub at the very least) will be killer. -
Inappropriate?Integrating Sifter elegantly with all of the other development-oriented applications out there is definitely a high priority. Source control is one of the highest priority integration points.
-
Inappropriate?Providing an API would help our team as we've come to rely on github integration for ticket management -
Inappropriate?having an API is a must have for us to use the service, specially to integrate bug reports into our publicly available software
I’m neutral
-
Inappropriate?Get an API and I'll write all the glue for github and such, as I would love to have integration. :)
On top of an API, I would love to see web hooks along the lines of GitHub's services. You wouldn't need anything that complex, but doing a simple post to user provided url's would make it really easy we developers to build various notifications in (campfire, twitter, etc.).
I’m happy
1 person thinks
this is one of the best points
-
Inappropriate?Garrett, as I mailed you previously and API would be most welcome so that we can integrate sifter into our process. -
Inappropriate?Adding my voice to the "just waiting to switch until there's an API" chorus. We have over 40 Trac projects with active tickets I need to be able to automate import for before it's feasible for us to start using Sifter.1 Comment Add a comment
This is one of the best points
-
Good deal. Thanks for letting us know. We definitely hear you load and clear. It looks like we'll be making some significant interface changes that will be directly related to us supporting an API that will slow down the API a little, but it's a huge priority for us.
-
Inappropriate?Our team needs to write a sync tool between sifter and jira. We have good people and plenty of cycles to dedicate to this (yay for inefficient corporations!). However, this issue looks stagnant. What is its status? What can we do to help?1 Comment Add a comment
This is one of the best points
-
It's becoming a hotter topic as we're encountering a fair amount of people who would switch if they could import their issues from other systems. In my head, I've lumped the API and more advanced import/export functionality into the same group of related work as the API could probably alleviate the need for additional export options.
Right now, I'm in the middle of a significant refactoring of our billing and back-end that has consumed much more time than I had hoped. (I'll be blogging about this soon.) I'm planning on wrapping it up in the next couple of days, and then we'll be determining where to head next.
The API is one of the two hot topics with the other one being help desk and email functionality. However, we've been hesitant to invest too much time in the API until we fully understand the changes that the help desk functionality will bring about because we don't want to release the API and then immediately write an entirely new version the next month to support the help desk functionality.
Also, based on the conversations we've had with people, many want an API in order to hack Sifter into working as a help desk the way it is now. So, if we can save them the effort, we'd certainly like to do that and get the help desk side built sooner rather than later.
So, it's not days away, but it's about to start getting more attention. I know it's been a long wait, and I do apologize for that, but I promise that we're doing our best to make all of the right long-term decisions for Sifter.
In the mean-time, it certainly wouldn't hurt to hear some specifics of what you hope to do with the API so that we can have a better understanding of what you'd like to see. Feel free to email me directly or use our support request form. Thanks for the nudge, and sorry again for the delay. -
Inappropriate?REGARDING EMAIL CONVERSATION AROUND ISSUE
# Need:
-Reply to an email to comment in the conversation
-Receive direct link to attachments
# Nice to have:
-Attachment on email is added to issue
-CC someone in the reply to add to issue's future updates (conly if he has account)
REGARDING INTERACTION WITH OTHER SYSTEMS
# Need:
-Be able to send out a message from Sifter to other system each time an issue is created or updated. For instance an HTTP POST could be sent to a configurable URL with each create or update of an issue, so that a script adds a message or comment in Basecamp.
-Be able to create or update a message in Sifter from other system. For instance, an HTTP POST could be sent to http://demo.sifterapp.com/projects/11... with the authentication header with the API key value (you would just need a way to create this key and update your auth system to accept that user)
A simple response set, like:
200 for success
401 for unauthorized access
500 for failed
would be enough feedback from Sifter
This poses the issue of how to send category, priority and assignee without knowing their codes. I suggest category and priority be sent as a string that matches Case Sensitively and assignee through username. In any case if the data doesn't represent an existent value, leave undefined or set to default as your model constraints.
# Nice to have:
-Be able to update issue status, category, priority or assignee in Sifter from another System
Hope this is useful.
Regards,
n.
I’m excited
3 Comments Add a comment
This is one of the best points
-
It's definitely useful. Naturally, some of it is easier said than done, but you mentioned a few things that I hadn't considered yet.
For category, milestone, priority, assignee, etc. I expect that Sifter will enable you to retrieve lists of those values for any given project.
Thanks for sharing this! -
I'd like to be able to integrate Sifter with Basecamp and more specifically the to do list. I could see wanting to integrate Harvest also, but I'm not at that point with my team.
So I think I'm in agree with cubetto, but I'm less concerned with the specifics. That said I have preference for (truly) RESTful APIs. Didn't recent version of Rails make that easier? I seem to recall DHH gushing about that a year or so ago. -
It will definitely be RESTful, and yes, Rails is very REST friendly.
-
Inappropriate?I would love to build an iPhone app using a Sifter API. Mainly for viewing issues, but adding and editing would be awesome too.
1 person thinks
this is one of the best points
2 Comments Add a comment
This is one of the best points
-
Good deal. We'd definitely love to see Sifter get some iPhone love. :)
-
There is a sifterapp shaped space on the app store at the moment, something with similar functionality to Tweetie.
-
Inappropriate?adding another voice to the chorus of "waiting for API" - please don't try and build a help desk system first, that would be a mistake.
everything cubetto requested is what we need.
I’m waiting impatiently :)
-
Inappropriate?And one more! Really needing an API so that I can extract issues along with associated milestone dates into some sort of table based view.
Cheers,
Rob -
Inappropriate?We've officially started on it. There's no ETA, but it's receiving 100% of our attention until it's ready. It will be RESTful and use Oauth. Naturally, we'll post here when it's ready.
I’m excited
The company thinks
this is one of the best points
-
Inappropriate?Too little, too late. We've pulled out of sifter. A month ago I offered significant time from 4 really good developers and got nothing. Instead, we're stuck with Jira again.
I’m underwhelmed and now stuck with jira
1 person thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
I'm sorry to hear that, but we have to make the best long-term decisions for Sifter. Unfortunately, It didn't make sense to switch our focus away from the release we were already working on. We've finished that, as I stated that we would in the earlier response, and now we're moving on to the API. I'm sorry our timeline didn't work out with what you needed.
-
Inappropriate?This isn't a matter of the last month... it is a matter of the last 12 months. This is far beyond a matter of "focus" for the last release.
I’m disappointed
1 person thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
Again, I'm sorry we couldn't live up to your expectations.
-
Inappropriate?Brilliant. Hopefully we'll be able to integrate it in the QA Loop on our next release : )
I’m excited
1 Comment Add a comment
This is one of the best points
-
Just remember that we don't have an actual date yet. We're focusing all of our effort on it, but it will still take time. :)
-
-
Inappropriate?Very exciting! Looking forward to building a burndown chart plugin for sifter :-) -
Inappropriate?Any update on the status of the API? We need to know if this is happening soon or we're splitting...
1 person thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
We're working on it, but we're not making any promises about dates. It will be the next big release.
-
Inappropriate?agreed. it's been a year. a simple API ain't that difficult. please deliver, or we're also moving on to another product.
I’m disappointed
1 person thinks
this is one of the best points
-
Inappropriate?I've been thinking the same thing - it's gotten pretty ridiculous.
-
Inappropriate?We're working on it, but it's not going to be here in a matter of weeks. In general, I would advise anyone who is unhappy with any product not to use it. Naturally, we hate to see people go, but I'd sincerely rather that people be happy, even if it means that Sifter isn't the right product for them.
The last few months have been incredibly busy for me personally, and the reality is that Sifter can't support me full-time. It's getting closer, but it's not there yet. So sometimes, the bills have to be paid.
We've been working on making some important changes to make sure that the we can spend a more consistent amount of time on Sifter. Unfortunately, it's a significant transition, and it takes time. It's not as if we said we were working on the API and then released dozens of other features instead. We simply haven't had the development hours to spend on it. That's changing, but it takes time.
We are investing all of our development time on the API. In order to do it well, and have a clean RESTful implementation, we're also going to make some other changes to the interface to help simplify and tie everything together neatly. That also takes time.
We could rush something out the door, but we wouldn't be happy with it, and neither would anyone else. I'm sincerely sorry that our rate of development is fast enough for your expectations. We're not very happy with how long it's taken either, but we want to do this the way that we feel is right.
We're working on it. If you need it immediately, then I'm sorry, but we're going to disappoint you. I assure you that we're trying to make the best long-term decisions for the application and for our customers. We believe that focusing on speed of delivery is a mistake, and we're not ever going to do that.
I’m optimistic
The company and 1 other person think
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
A very clear and fair reply, thanks.
-
Inappropriate?Garrett, while I agree with many of the points you make above: do it properly; don't use a product you aren't happy with, etc. keep in mind that the only reason I'm willing to invest time is precisely because we *are* happy with the sifter UI and functionality - we just BADLY need an API so we can migrate projects to sifter and use sifter exclusively. Trac + Sifter = PITA
The API is *the* thing standing between you and a healthy full time salary from this product (+later scale to happy profit). I'd be happy to pay part of that salary if I could migrate everything to sifter. right now, I can't, which makes life harder.
For example, my organization currently has a 'small' plan @ $29 monthly.
With API and Trac import your revenue from us would *instantly* more than triple to $99/month.
My situation is doubtless similar to the others here whining about the API.
best,
_alex
I’m waiting ;)
1 Comment Add a comment
This is one of the best points
-
I completely understand, and nobody would love to have an API out tomorrow more than me. I assure you that I'm 100% focused on the API at this point and giving it every ounce of time that I have.
Hopefully it will have been worth the wait when it arrives.
