Lulu Developer Blog

RSS Feed

One new API and one reworked

Earlier today we released our brand new File API.  Previously, uploading files was two calls, one to request a token and another to upload.  With this new API, it is a single call, just upload the file to us.  Another issue is that once the file was on our servers, the developer couldn't do anything with it.  A common request was to be able to find files that had been uploaded previously and use them in future projects.  With the new API you can get a list of all files that you have uploaded, as well as search for files that match specific criteria.  This API also attaches a unique identifier to each file, which will allows you to use the files in your projects with greater ease.  Finally, the new API allows you to download files that are in your workspace.  The original upload API will continue to work for either a year or until we have determined that all users of the API have migrated to the new system.

As we released the new File API, we also completely revamped the Cover Creation API.  This system allows you to send us specifications, and we will generate your cover based on those requirements.  The old system required your images to be available on a public web site which we could pull from.  This new system allows you to upload your images through the File API, and use them in your covers.  The goal for this change is to make cover creation easier to use.  At the same time, we took the opportunity to simplify the cover specifications.  We have removed the layoutDefinition block and we have removed all id elements from within the layout and background blocks.  These sections weren't used by the old system, and are ignored when sent to the new API.  The new specification message has added a templateId and spineWidth element to provide enough details to generate the cover.  As with the upload API, the original cover generation API will continue to be supported for up to a year, or until we can prove that all users have migrated to the new system.

Our goal with these changes is to make the publication APIs easier to understand and use.  We hope that you like the new system, and we welcome your feedback.


Show Me the Money: How to Earn Some Dough with Lulu’s APIs?

One of the most common questions we receive right now is how to earn money with our APIs.  Most of our developers who have tried have also successfully published books.  But the line between a newly published work and getting paid isn’t as clear as we’d all like it to be.  So my goal this post is to make it much easier to understand how you, as a developer, can start growing your wallet.

 Before explaining how to earn money through our APIs, we need to review the standard equation for earning money with Lulu in general.  Our model is to align our goals with our creator’s goals.  This means that we want you to sell more books as much as you do, because we don’t earn any money until your book sells.  The same model works for our API developers.  For the examples below, I am going to use easy round numbers to illustrate the point.  I am also going to ignore distribution for the first example, but we’ll get to that below.

Assume that you sell your book on Lulu for $15.00, and the manufacturing cost is $5.00.  The remainder is $10.00, which we split 80/20 - Lulu gets $2.00 and we pay the creator $8.00.  This is the standard relationship between Lulu and our creators.

If you are an API developer, you have the option to partner with us the same way.  Publish your book, and if it sells on Lulu, we will pay you 80% of the sales proceeds above the manufacturing cost of the book.  The other option is what some of our existing API developers are doing.  They sell the books on their own site, and come to Lulu to buy the book under their account.  When we sell a book to the creator of the book, we don’t charge the full retail price, instead we charge the author our manufacturing cost.  Let’s use the same book as we used above.

 Assume that you sell your book on your site for $15.00.  Now you come to Lulu and purchase the book yourself giving us your client’s address to ship to.  You pay us the $5.00 manufacturing cost, and pocket the full $10.00.

 The obvious question is why anybody would use solution #1.  With solution #2 today, you need to enter the order manually through the site.  The new E-Commerce APIs being released next week will fix that and allow you to automate the order placement.  However, those APIs require a contract between you and Lulu, and they won’t be available to everybody on day one, as we work through the relationship model (who gets called for support, how do you escalate issues to us, etc).  The second reason to use option #2 is that it means you don’t require your own E-Commerce engine.

 Everything changes a little when books get into distribution.  So, if you decide to sell your book on the iBookstore or Amazon, the options become a bit more limited.  The order will come directly to us from the given retail partner.  When your book is sold on Amazon marketplace we remove the retail fee, then the manufacturing cost, and then we split the rest 80/20.  Let’s see our example again.

 Your book is sold on Amazon for $15.00, and they take $2.00 as their fee.  We remove the $5.00 manufacturing, leaving $8.00 to split.  You get $6.00 and we take $2.00.

 There are other options too, such as our publisher and partner programs, which we will review next month as well.


Updated All Documentation and Dates for the Next API Methods

It took me a lot longer than I originally intended, but all of our public facing documentation has been updated!  Take a look and let us know if it's easier to understand.  We will continue to extend the documentation and add more information to make developing against our system even easier.

The other piece of good news is that both the new Document Conversion and Order Ingestion APIs will be live on March 22nd.  Both are documented now, though the APIs aren't actually live yet.  Feel free to offer any feedback on that documentation as well. 

Over the next few weeks, we'll be reaching out to individual developers to get involved in our limited beta for the Order Ingestion API.  We will start with those developers that we know are already submitting orders manually, and then expand to include other developers also interested in Order Ingestion capabilities for their sites and projects.  Once we have had some success with this API, we'll expand beyond the limited beta.

Designing the right API takes time

Last month I committed to releasing two new APIs on February 22nd:

  1. Document Conversion
  2. Order Ingestion

As you may notice, it is the 22nd and we have no documentation for these new APIs on the site yet. We are delaying the public release of both of these new APIs to make them even better.

Striking the right balance between quickly getting new APIs into the hands of eager developers, and taking more up-front design time to ensure each API we release is valuable, easy to use, and sufficiently scalable can be tricky.  Fixing issues in future releases is always an option, but we want to avoid placing an undue burden on our developers who must modify their systems whenever major changes are made.

From this point forward, we are going to do more up-front design work to ensure that each API we release is consistent with the rest of the APIs.  To date, we have done this by creating the client libraries at github.  While that is a good first step, it is only the first step.  I am in the process of creating a demo application that will also be hosted at github and allows people to publish books through our API.  We are considering publishing documentation for comment/review prior to releasing the API.  If you have any other ideas to help with this effort, please let us know.  After all, we know that the success of our APIs is based on you.

I am working to get a formal release date for the two APIs this week, and will post again once I have a firm date.  We are also working on our new Shipping Cost Calculator API, that will enable developers to determine the shipping cost for any given shopping cart.  Be on the look out for more specific release information on this API in our upcoming posts.


Lulu APIs powering other companies

Last month I reviewed some of the exciting projects that Lulu is working on.  This month I want to focus on what you have been up to.  We released our first version of the publication API in the middle of 2010.  On January 13th, we have added the ability to track the number of books that each application has published.  I thought it would be fun to review how you all are doing:

In the second half of January, we had 8 applications publish 137 books.  Just over half of those books were published by just one application.  If we remove the books that were labelled as tests based on the titles, the rest of the applications published about the same number of books.  If we look at when the books were published, again, ignoring the 74 published by one application, the books were published at a rate averaging just over 4 per day.

But, that is only part of the good news.  If we look past the publications to which books have been purchased, the news is equally positive.  Of the 8 applications that published books, four applications had books purchased.  In fact, those four applications sold close to 15 books each.  Remember, we are tracking those books published between January 13th and January 28th, which also means that we are only tracking purchases in that time frame as well.

We are very excited to see our partners doing so well with our publication API.

I also wanted to give a quick update on our progress.  I have rewritten some of our documentation, not as much as I wanted, but I am continuing to work on this as time allows.  Please let me know what you think of the new authentication/authorization documentation.

We have two new APIs coming at the end of February:
    1)  Document Conversion - Today, you can bring us a PDF file.  At the end of February, you'll be able to bring PDF, Word documents, RTF,  or HTML.  We will convert the files to print-ready PDF and publish the book.
    2)  Order Fulfillment - This will be a limited release of an API to allow users to specify a list of orders for Lulu to fulfill.  The API user will be billed for these orders at the end of each month.

As these APIs are completed, I will post more information about how to get access to the APIs and how they work.  If you want your application mentioned in our application gallery, don't forget to let us know through or by responding to any blog post.  You can also follow us on twitter now.


New APIs coming from Lulu

I wanted to take a little time and explain some of the new and exciting things that we are working on.  This will become a regular theme of our blog, so that you all know what we are working on.

New Documentation

Coming very soon, you will find our documentation has been completely re-vamped.  We have taken the questions from our current users and realized that we can handle most of them by spending more time on our documentation.  Over the next few weeks, we will release new documentation for each API set that we have.  We are starting with the Authorization/Authentication section, then moving to Publication API, and then finishing with the Cover-Generation API.  The documentation will roll out as we complete it.  Once we have the new documentation complete, all new APIs will conform to our standard.

New Account Concepts

The account API right now is somewhat limited.  We will be extending our Account concepts in Q1 to include roles and permissions.  You will be able to set permissions as well as get the list of permissions that the logged in user has.  We will also be adding an "update" concept to the Account system.  This will allow you as the application developer to ensure that your users data is always up to date in our system.

New Publication APIs

The Publication API will continue to move forward with new APIs and enhancements to existing APIs.

We are starting with a "save as draft" system that allows you to upload partially complete projects in draft mode.  Once the project is complete, you will be able to complete the publication process.  This will let your users leave your site and know that their data is safe in our repository.  We will also introduce a File API that allows you to upload files to Lulu that aren't intended for immediate publication.  These files will be deleted after a few weeks if they aren't published, but it provides a staging area while you are working on a project.

The next feature is document conversion.  Right now, through the API, you are restricted to uploading PDFs or ePubs for publication.  We are actively working on a system to allow you to upload Word, PDF, or image formats for publication.  This system will also allow simple file conversion, so if you have a Word file, we will automatically convert it to ePub or PDF.  The files will be available for download through the File API or through the My Files section of

New E-Commerce APIs

To begin our E-commerce API work for early 2011, we are working on a Royalty system that will allow you to track Royalties and report on the amount of money each author should be paid.  We are also working to support setting Royalty ratios on a per book basis, so that you can determine payments differently for each book published.

We know that you want to drive your e-commerce from our engine, and we are working to allow that.  The first API will allow you to send us orders as an XML document and we will fulfill and ship to your end users.  We are also working on Shipping and Tax APIs to allow you to determine shipping and tax costs. Finally, we will be creating an "Add to Cart" API that will allow you to create a shopping cart for your end-users, and then send them to our site for the checkout process.  

We are very excited about these up and coming projects, and hope that you are as well.  I'll keep you up to date with the progress!


New Developer Graphs

Last week we released a feature on our developer portal that we are very excited about.  Since we released our APIs, we have been able to monitor how you, our developers, are using them. We found that a key element that was missing was the ability for each of you to monitor your own usage.  Well now you can! If you go to the "My Account" page, there are a number of tools that you can use to monitor your API usage.  For each key, there is a "View Report" link, go ahead and click on that.

Each API has a rate limit, that controls how many calls you can make per second and per day.  This protects the APIs and ensures that one developer doesn't accidentally take the system down for everybody else.  At the top of the page, you can see how many of the 1000 calls per day you have used:

After looking at what you are doing today, you can also look at the calls made over a couple of different time frames.  The goal behind these graphs is to let you see how many calls you are making per day.  If you find that you are coming close to the limit on the API, let us know.  We can increase your limit if we need to.

We hope that you enjoy having access to all of this data about how you use our APIs!


Lulu APIs are Ready for the Big Leagues

This is our first post about the new Lulu APIs so I thought I would start by explaining who I am, what we are doing, and what you can expect to find in this blog in the weeks ahead.

Firstly, I am Ryan Bloom, the Senior Director of Engineering for Lulu.  I am a developer at heart and still hack on code when I have the time.  Years ago, I was involved in the Apache HTTPd server, version 2.0 and the Apache Portable Run-time, which led me to write and publish my book, "The Apache Server 2.0:  The Complete Reference."  That book is one of the primary reasons that I am at Lulu now.  

Writing a book is hard, and getting a publisher to accept your book can be even harder.  Anything that can make the writing and publishing process easier means that knowledge is more readily available.  Even better, with a site like Lulu, fixing errata and making revisions is significantly easier.  When my book was released, I had people send me small errors that I couldn't fix. For a while, I kept a list on my web site, but it was never satisfying for me.  With Lulu, I could have easily fixed the errors for free and made the the experience better for the next reader.

Lulu is made up of a group of mild-mannered folks in Raleigh, North Carolina looking to do nothing short of making the world a better place. Our goal is to give anyone the means to share their voice and ideas through a platform that provides all the tools and resources to become a successfully published author. Creators are in complete creative control, while Lulu handles the minutia of royalty payments, fulfillment, and distribution. Our APIs are setup to allow developers (you) to help write these tools, both for your own success, and for the success of your clients.

Right now, we are focusing on releasing application building blocks through our API.  Future APIs will also expose data too, but the first thing people want to do with our platform is take action, so initially we’ll be covering book and cover creation, and book publishing. With these tools, you can take any manuscript and create a book that can be delivered to somebody's front door within a few days.

The best feeling about this is that it is working.  We already have developers creating applications that make real physical books and e-books that are available for sale.  And we are only going to get more and better APIs.

In the coming weeks and months, this blog will provide first hand information on what Lulu is doing that is unique and cool, as well as how you can use our APIs to further your projects – like getting your books into the iBookstore. I will also highlight what Lulu is doing with the developer portal and which APIs you should definitely be watching, such as the the developer reporting API we rolled out yesterday (details in the next post).

Lastly, but most importantly, this blog is your opportunity to talk back to us. So please feel free to offer suggestions, join in the conversation, or start one of your own.

[ Page 1 of 1 ]