Check out the data set from this post over 1 and half years ago. On top of the basic data set's year, make and model, the complete data set comes with data like MSRP, MPG (city and highway), dealer invoice, gas tank size, etc.

We get tons of hits for basic data, but at no additional charge we also provide the complete data set. Just add a complete
=> "true" to your request. So simple and there's no performance hit.

For more information, check out or examples and faq.

Enjoy!

Here's another look at the data elements from a comprehensive query:

Anyway, we thought we'd share our little trick to get page headers using the spreadsheet gem.

So what you see here (above) goes into a config/initializer, something like RAILS_ROOT/config/initializer/enable_headers_in_spreadsheet_gem.rb. Here's what's going on:

1) We know that the write_from_scratch method is called when everything is said and done and the data is ready to be written to the spreadsheet file. So we make use of this and alias that method to write_from_scratch_without_header. Which opens us up to call our write_header method inside our write_from_scratch method which, of course, will call the original write_from_scratch method.

2) Our write_header method makes use of the already existing opcode for Header in the spreadsheet gem. It's not being used, so my guess is the developers intend on solving this issue at some point. We have to send the opcode, the length info and the string we want to write out. This was the trickiest part to figure out.

3) We expose an add_header method that simply takes a string and stores it in the header accessor. This means, to set the header, you simply say sheet.add_header("foo header").

To implement the footer, you'd just do the same thing, create a footer accessor, add a method to update it. Then build the writer_footer method with opcode(:footer) and append write_footer at the end of write_from_scratch.

Well, that took us some time to figure out, so enjoy and let me know if you have any questions.

Ok, so what did we decide to do? Well first, and most importantly, we decided to keep the service up and running; for a while there it was looking pretty bleak and if you take a second to look at the numbers (financially) you can understand why. Anyway, to be as fair as possible, we did not feel this could be monetized as a subscription-based product, some months you need 500,000 VINs and some only a 1,000. Looking at the data for year, we had many questions - what plan would you pick? should the plan rollover it's unused decodings?

We discovered a lot of complexity in the subscription model, so we decided to setup the pay as you go plan, where you buy your decodings at various bulk levels. For instance, you could buy in groups of 1,000 or 10,000 or 100,000 such that you would realize savings on a price-per-VIN basis the larger the group you purchase. There is no use policy either, so you can sit on the VINs for as long as you want, or you can even buy decodings the day (even the minute) before you need them. No monthly credit card bill, no rollovers, just simple "buy what you need," and if you buy in bulk, you save.

Another consideration in doing this was having to maintain soft limits. For example, if the user purchases the 5,000 VINs per month plan, and the their site does well this month and they need 6000 VINs, should they have chosen the 10,000 VIN plan? We didn't think so, we figured no hard limit, just soft limits, and after the soft limit is hit, we would charge the additional VINs at the current rate per VIN to the user's next month's bill. We tried to explain this to a few current users that are helping us come up with reasonable rates and they were not all that thrilled about it. So we had a problem, we did not want users to pay for what they did not need, but at the same time we did not want to cut users off in the middle of a month when they hit their limit. That entire idea had to be scrapped and along with it went the idea behind the subscription plan itself. We like it though, it's simple now - buy your decodings and use your decodings, we will email you if you are getting low and may want to add decodings to your account.

Subscription models are great for static resources and static services, but not a single one of our customers decodes the same number of VINs each month, so it just won't work. So onward and upward, pay as you go and regardless of how the other API providers offer their service, we are excited to be a little different and lot cheaper as you will soon find out.

Enjoy!

And for PHP, you have this:

Hope this helps and if you have examples for other programming languages, please let us know.

If you use ruby (look for a future post with .NET and PHP examples), and want the complete dataset, you would setup your ActiveResource like this:

And then call our API like this:

The only change (for those of you who have already implemented phase I) is to send in a "complete" parameter with value of "true" ... upon doing so, VIN API will send you the complete dataset versus the basic (and default) dataset.

The results would look like this (in XML) and be prepared because it is lengthy:

That's it, just thought I'd share VIN API's Phase II.

Using VIN API:

This is explained in detail at VIN API's site, but I will give you a look at what it does here.

If you use Ruby on Rails like I do, then you have the option to use ActiveResource:

Then you can use it like this:

Current Limitations:

Right now each account is limited to 20 VIN requests a month, we are looking to take it slow and prevent abuse.  If you do need more VIN decodings a month, feel free to let us know at Mr. Quotey, we'd be happy to up the max for your account.

Where to next?:

It is too soon to really tell.  We'd like your feedback and to know if this service is useful.  If it gets enough buzz, we would probably pursue it a bit more and drop the monthly limitations.