All the API calls support XML output, by adding &o=xml on the GET url line.
A number of the XML APIs support an &inc= parameter, which lets you specify which fields you want returned in your XML reply. This helps you get a very short reply, easier to parts and look at. In most cases, you will want to use inc= on your production code to decrease application latency. All replies are automatically sent via "gzip" compression when your browser-side indicates support for it. Try to use a mechanism that supports gzip compression if you are requesting large amounts of data: it saves about 90% of the bandwidth and radically decreases latency. Please do not do the equivalent of "auction sniping" http://en.wikipedia.org/wiki/Auction_Sniping and frequently poll BookMooch to see if your desired books are now available. That would be unfair to the other users on BookMooch, because you would always get the most books that everyone else gets, and I would have to ban you, in order to keep the "BookMooch game" fair. Polling once every 24h is fine.
Please limit your API calls to no more than 10 per second. If you serialize them, that should be fine -- just be careful if you have many threads/processes in your application calling the BookMooch APIs, that you aren't super busy at times.
If the userbook call fails, it is because that ASIN (aka ISBN) is not in the BookMooch database. You can have BookMooch import the book data from an Amazon store with the "amazon_add" call, and then re-call "userbook"
If you want to limit your mooching to people in your country, call "userid" for each of the people who are offering the book and look at "country" field to see that it is the same as your country. You may also want to be smart in your code, and for books that are offered by a lot of people, mooch from people who have the longest history of sending out books, and who also happen to be in your country.
Use the "mooch" call to actually ask for the book to be sent to you.