Lulu Developer Forums

API Development Community

RSS Feed

Managing multiple projects/accounts

  1. I'm new to this API, and before I get too deeply invested I wanted to check a few things.

    I coordinate projects for a volunteer-run publishing group, with 15 authors and about 50 books. Each author in the group has their own Lulu account, but I actually set up all the projects. I own a block of 100 ISBNs that I use for all of these. All the books are published under the same publisher name.

    1) Is the API set up so only one account can be accessed at a time, or is there some way of managing projects from multiple accounts simultaneously? For instance, to compare sales of books across multiple projects would I have to log in and out of every account each time?

    2) I'm guessing there would still be no way to order books from multiple accounts, at the author price, shipped together. If I were to work around this by having everything on one Lulu account, is there a way for projects to be set up so that royalties for individual projects go from Lulu to specific authors, or would I have to tally that up and disburse payments myself?

    3) I'm very interested in the e-Commerce API when it gets out of beta. Does it require a certain volume of orders, or have fees associated with it?

    4) Small thing - Lulu's own interface actually forbids me from using the exact same publisher name on two different accounts, so I need to do ridiculous things like adding extra punctuation and spaces for different authors. Does the API actually forbid this, or is it only checked on the Lulu front end?

    The more I look into this, the more I fear the API isn't going to suit our needs, but thank you so much for any information. I am very excited to see the progress being made with this.

    -- Joshua Tenpenny, Asphodel Press

    Message edited by Asphodel Press 1 year ago

  2. kviusr_12341 year ago

    Thanks for sharing!

    ftp server

  3. Josiah Gore1 year ago

    I apologize for the delay in responding. I hope I can answer satisfactorily. Let me know if you have any more questions.

    1) You can have multiple open sessions at a single time. Once you have authenticated with a given account, that auth_token will continue to be valid even if you subsequently authenticate with a different account.

    2) You're correct. Ordering at the author price can only be done within the context of that author's session, so ordering books from different accounts at the author's price is impossible. If you did put all the books under a single account, any revenue from those sales would be paid to a single remittance entity for that account, so you would need to divvy the money up appropriately.

    3) Use of the eCommerce API will not require a minimum volume. We have not made final decisions regarding API use tiers, but there will likely be no fees involved.

    4) By publisher name I assume you are talking about the publishing imprint associated with the ISBN you are attaching to the book? Yes, unfortunately it is assumed at a fairly central layer of our system that a single "owning" account can use a given ISBN imprint. We are looking at ways to take care of this sort of limitation by creating roles-based support for an organization such as yours, but for now this will continue to be the case.

  4. Asphodel Press1 year ago

    Hrm... I've been pondering this for a while, and with multiple open sessions I can see a range of possibilities.

    Since it is only a small subset of our books that we have ever needed to do bulk orders of, I could conceivably keep the current model where each author has their own account, and add a master account which has duplicate private copies of the more popular titles for doing bulk orders. And since uploading a duplicate copy of a book to the master account could be automated on my end, that becomes much more reasonable.

    I can continue to work around the limitation of only one account per publisher imprint as I have been. I was just hoping it was a simple data validation thing on the form, rather than a fundamental assumption of the underlying data structure, but no big deal. Perhaps by the time our organization is large enough to make that unwieldy, that role-based support you mention will be implemented.

    Thanks for your help.

[ Page 1 of 1 ]