Goodreads Developers discussion
bugs
>
isbn_to_id returns ids for invalid isbns
date
newest »

I was accidentally calling isbn_to_id for a value of '0' but my script didn't notice it since it was returning a valid id (lucky book # 11775988).
It looks like that book's record had an ISBN of '0', which is why you got it in your response. I removed that (invalid) ISBN. If you find more incorrect book records, you can request corrections by posting in "Book Issues" section of our librarians group.
You might also consider validating ISBNs in your application. Sorry, I know that's a little inconvenient. We'd like to do the same thing throughout our catalog, but it's not a simple or straightforward job.
I tried with a few other short numerics just to see what would happen and they also returned values (but seems to be just mirrors of the bad values -- e.g. call it with '1' and it returns '1'
This API method falls back to matching on book ID if it can't match on ISBN. This behavior is undocumented and (clearly) unexpected. I ran into this same problem myself a few months ago. I'm inclined to call it a bug, but it's long-standing behavior that we can't casually alter.
You can work around it by taking the ID given by the response, requesting that book record, and checking whether its ISBN matches your original request parameter. If not, that means we fell back to matching on ID.
It looks like that book's record had an ISBN of '0', which is why you got it in your response. I removed that (invalid) ISBN. If you find more incorrect book records, you can request corrections by posting in "Book Issues" section of our librarians group.
You might also consider validating ISBNs in your application. Sorry, I know that's a little inconvenient. We'd like to do the same thing throughout our catalog, but it's not a simple or straightforward job.
I tried with a few other short numerics just to see what would happen and they also returned values (but seems to be just mirrors of the bad values -- e.g. call it with '1' and it returns '1'
This API method falls back to matching on book ID if it can't match on ISBN. This behavior is undocumented and (clearly) unexpected. I ran into this same problem myself a few months ago. I'm inclined to call it a bug, but it's long-standing behavior that we can't casually alter.
You can work around it by taking the ID given by the response, requesting that book record, and checking whether its ISBN matches your original request parameter. If not, that means we fell back to matching on ID.

Keep up the great service.
I thought the ISBNs had a check-digit which made their validation easy, no?
Correct, but our existing catalog is huge, and we can't casually delete potentially thousands of non-conforming ISBN data. There could be lots of user data and URLs that rely on them, even if they're incorrect.
There are solutions, to be sure, e.g., start by validating all new, incoming ISBNs. But like I said, that's just one step of a bigger job. :)
Correct, but our existing catalog is huge, and we can't casually delete potentially thousands of non-conforming ISBN data. There could be lots of user data and URLs that rely on them, even if they're incorrect.
There are solutions, to be sure, e.g., start by validating all new, incoming ISBNs. But like I said, that's just one step of a bigger job. :)
I tried with a few other short numerics just to see what would happen and they also returned values (but seems to be just mirrors of the bad values -- e.g. call it with '1' and it returns '1', call it with '0123' and it returns '123'). Other invalid values such as "x" returns the expected "No book with that ISBN".