Using curl to create new tickets in xml file

Thomas Gaylard (Admin)'s Avatar

Thomas Gaylard (Admin)

17 Oct, 2014 05:24 PM

I am trying to use the curl command to create a set of tickets defined within an xml file.

curl -X POST --data @lighthouse-create-tickets.xml -u user:password -H "Content-Type: application/xml" https://<myaccountid><myprojectid>

I get the following response:

<html><body>You are being <a href="">redirected</a>.</body></html>

The xml file is a dummy file with a very simple ticket in - here it is:


Can you help me understand where I am going wrong here?



  1. 1 Posted by Julien on 17 Oct, 2014 05:40 PM

    Julien's Avatar

    Hey Thomas,

    You can take a look at the KB but I see at least 2 things that stand out:

    • You can only create 1 ticket at a time, So your root should be ticket not tickets.
    • You need to post to /projects/ID/tickets.xml

    Can you change that and tell me how it goes?

  2. 2 Posted by catchall on 18 Oct, 2014 12:31 PM

    catchall's Avatar


    Thanks for the quick mail and helpful response. Yes I changed both those things and it works. Thanks a lot.

    Just a couple of points of feedback.

    1. Before contacting you I spent quite a lot of time looking through the KB to try to find the information I needed. I found it difficult to find exactly what I wanted and I’m not convinced the answer to my question is there explicitly. Given how precise you need to be when using the API I would expect to see a bit more of a structured manual rather than just lots of articles in response to specific queries, which makes it quite unstructured.

    2. I was a bit surprised that you can only raise one ticket at a time like this. I am using the tickets to set out a number of tasks required for my project. Also when I test I tend to make notes and then raise a number of tickets at once and I can’t believe I am the only person who would like to raise more than one at a time. I will need to write a script now to loop round my tickets and create a ticket for each one, which I would have preferred to avoid.

    Any I hope the feedback is taken in the positive way intended. Feel free to come back if you think I can do what I want in a better way.



  3. 3 Posted by Julien on 20 Oct, 2014 01:14 PM

    Julien's Avatar

    Hey Thomas,

    Feedback is definitely always welcome.

    API documentation

    It could definitely be more substantial, with more details, caveats, etc.

    Bulk creation

    To be honest, while I can see how it would be useful, unless you are going to create hundreds of tickets at a time, creating them one at a time doesn't feel like such a big deal to me, and is how REST works. Do you have examples of APIs you use regularly that offer bulk creation?

    Also, Lighthouse is a system for humans, not automated errors, so tickets tend to be created one at a time, even if it is in rapid succession.

    I guess we could have a bulk option, but considering other things we have to work on, it is not a high priority.

    Let me know if you have any question.


  4. 4 Posted by Catchall on 20 Oct, 2014 01:41 PM

    Catchall's Avatar


    Thanks for, again, a quick and helpful reply.

    To be honest I'm probably using Lighthouse in a way it wasn't designed for. I sometimes use tickets as a placeholder for tasks I need to do to reach a milestone, rather than just to record issues. Because of this I am wanting to set up a ticket for each of the steps, in advance of doing them, which is why I want to set up more than one at a time.

    I am stretching LH beyond what it should be used for so I am thinking I should use something else for this, and use LH just for tickets. I am considering Pivotal Tracker to plan my work, but if you have any other recommendations I would be interested to get your thoughts. PT integrates with Lighthouse which is a strong point in its favour.

    I do all of my development on my own, so I don't need an industrial strength Scrum collaboration tool, but I need to be able to plan and track my work and occasionally collaborate with one other person.

    Any thoughts?


    Sent from my iPad

  5. 5 Posted by Julien on 20 Oct, 2014 01:58 PM

    Julien's Avatar

    Well, there is nothing wrong with using a ticket per task / development item. What we often do, regarding milestones, is have a ticket called "FEATURE OVERVIEW" that gives a bird's eye view of the feature/milestone. Then we use tickets for individual chunks. The idea is that we break the milestone in individual pieces that are as independent as possible so they can be worked on, tested, QA, etc., separately (or linearly, providing breakpoints).

    I would not recommend necessarily creating a ticket for every small item. For example, if you have a task that is "CSS/design for page X", you would list the individual smaller tasks inside the ticket, rather than creating new ticket. For this kind of tickets (development of features), I tend to just edit the main body of the ticket and have a running list like this:

    * foo
    * bar
    * baz

    As I go through the list, I just re-edit the ticket to keep it up-to-date.

    This is a workflow for development, and I use a different workflow for bugs. For bugs, I do make individual tickets for each bug, and I put as much details as possible. We reference bug numbers in commits and branch names, so that when you look at the log of a file or a line, you can understand exactly why it's there by looking at the ticket.

    You can also look at, it's a good way to keep a roadmap and decide what to work on next. We sometimes use it for general planning and then keep the actual details in Lighthouse.

    Finally, you can look at this article as well: When I work on big tickets/descriptions, I prefer working in a dedicated Markdown editor.

    Hope that helps.


  6. 6 Posted by Catchall on 20 Oct, 2014 02:03 PM

    Catchall's Avatar


    That's really helpful. Lots of useful information and food for thought. Thanks very much.


    Sent from my iPad

  7. Julien closed this discussion on 27 Oct, 2014 02:33 PM.

Discussions are closed to public comments.
If you need help with Lighthouse please start a new discussion.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac