This is a really clever idea. So simple and almost-obvious, yet it's the first time I come across this. Genius.
Particularly like the fact that REST APIs are pretty easy to start with providing GET access to resources, but get messy when you start doing POST, PUT, DELETE, PATCH etc. In this case, it's read-only by definition. That must make things so much easier. I can anticipate people asking for update access in future, but if you can get customers without it, I'd hold off with that for as long as possible.
One thing though - I think you should definitely raise your prices. 20Gb and 10 million queries for only €15 per month??!!
This strikes me as different. This looks a lot like Microsoft Access. A tool for "simplifying" database construction and common tasks like reporting (which doesn't actually work except in very simple cases, because you quickly reach the point of needing to understand concepts like normalization and foreign keys even if the GUI is pretty).
Thanks! I too was surprised when I couldn't find anyone else that had done it. Noted RE pricing, just testing the water for today - consider this a HN special if you want to lock it in early ;)
I'm guessing I'm simply not considering the target audience, but so far as I know the groups (people who communicate primarily via spreadsheets) and (people who know what an API is) have a fairly small overlap.
Maybe I'm just underestimating how widely used spreadsheets are for communicating programming information. I've never seen it, but hey, I've never seen a lot of things.
I can only speak for my use case, but I've heard similar things from other people, so I don't believe it's only me. I agree the overlap is small between those groups, but I think it's pretty painful when it does occur.
I've done quite a bit of freelance web development, mostly in the telecoms and infrastructure sectors, and there was often a requirement to integrate with a third party. This "integration" almost always took the form of periodically receiving spreadsheets from them, manually importing them into our database, and then also handling the periodic updates. And the apps I was building only needed to query a few rows each day! Sometimes they'd eventually create an API, but most said they couldn't or wouldn't due to time or complexity. Sheetlabs is my attempt at removing some of these barriers.
Anyway, that was _my_ itch, and this is how I'm scratching it!
Excel 2010 and up have the ability to read from web services that support Microsoft's OData protocol, and Microsoft is pushing some add-ons they built for Excel to turn it into a more robust front-end for business intelligence things.
So I don't think it's about knowing Excel and knowing what an API is as much as that you can train someone to paste a URL in and then they can build their own reports/worksheets that join in your data.
Pretty much what I wanted to say. The target seems to be "business" people who email spreadsheets around, and if you haven't seen this much, believe me it is done a LOT. But in my experience these people would have no idea what an API is and no idea why they would want one. I see these people gravitating to shared spreadsheets on Google Drive or SkyDrive, which eliminates the email attachment pain without really requiring them to learn anything new.
The idea is cool, the website looks good, and this seems like it could be really useful, but I don't get the sense that the right audience is targeted here.
Also an aside to the Sheetlabs folks, sort of a pet peeve of mine, your site returns a blank white page if JavaScript is disabled, you might want to at least throw a noscript tag in so people don't think you are just down.
Author here. Thanks for all the feedback, very much appreciated, I wasn't expecting this. Feel free to email me if you have questions you'd like to take off-list (email in profile).
Some stats, which may be useful for anyone doing a Show HN soon and wondering about volumes:
- 11k visits at the time of writing (3 hours in)
- 71% of hits so far are from the Americas (hit the California server), 29% from elsewhere (hit the London server). Given the time in Europe, there is significant bias here though.
You need to put up some examples of what can be done by this service. Something visitors can interact with without registering is ideal to convince them to register.
I stared at that for 10 minutes trying to find the spreadsheet. I assume there is a spreadsheet backing it? You should actually show people the spreadsheet - just seeing an API description without demonstrating that it runs off a simple spreadsheet almost kind of defeats the whole purpose of the service!
Thanks for the feedback. Yes, it is backed onto a spreadsheet effectively. Showing it is a good idea for the front page.
But I don't think showing the spreadsheet in the API docs is so useful; the idea is to present a clean API to the users, and they don't even need to know that the data was originally from a spreadsheet.
+1 on showing the spreadsheet. It doesn't have to be on the docs, can be on the website. I'd put front and center, if you have this spreadsheet, it creates this API. You can even look into giving access to the sample spreadsheet for testing directly from the web pages.
Very interesting idea: one possibility for driving demand would be to provide free API hosting for public-domain spreadsheet data (essentially anything published by the government) and charge heavy usage users for access (they could eventually just import the source data if they cared that much, but it could help get the word out).
I've been thinking along very similar lines, but more along a Github-esque model: Host your data and APIs for free, providing you publish them publicly. If you take them private, you pay a little. Early days yet, today is mostly about gauging interest.
Hehe: I was trying not to use "Like Github for APIs" in my description, but yes, that is pretty much what I was thinking.
I actually just ran the following search on Google:
inurl:.xls site:gov
and uncovered a bunch of random Excel spreadsheets (such as this one: http://www.whitehouse.gov/sites/default/files/omb/budget/fy2...). Would be slightly more complex to do but potentially this would make any published government data instantly accessible via API and (depending on what your backend looks like) you could bake in Solr or ElasticSearch to also provide search inside the data. Maybe an easy onboarding tool to let any visitor to the site specify a publicly accessible spreadsheet and then automatically create the API?
This is really cool, and a nice implementation. My question is about target customers. Presumably, you have two sides to this: non-devs writing and uploading the spreadsheet, and devs writing a client to to consume its API. I would imagine these two parties would be in the same company. e.g., Sales team wants some analytics dashboards written over their spreadsheets. So they upload a sheet and give it the API to devs, and then the devs consume the API, analyze the data, and pull it into a dashboard. Also presumably, it would be the devs recommending to the non-devs that they upload their spreadsheet here for easy access.
But if this is the case, why would the devs choose to use this over any number of CSV or XLS parsing libraries? You can write a simple web server that takes a spreadsheet as an upload, and then parse it to CSV, in less than 50 lines of code. The CSV reading APIs in any language are very easy to use and parse to native data structures, and I would argue maybe even easier than using an API like this.
What is your value proposition to devs in this scenario? Or I missing an entirely different use case?
Your two sides scenario tallies with my own, except I'd imagine they're not usually part of the same company (but other people will have different use cases, of course).
In your example, you could absolutely use an existing CSV or XLS parser to do this. The problem is that you're now responsible for making sure that you've got the latest data, have parsed it, and have imported it. As a developer, Sheetlabs allows you to put the onus back on the data publisher to ensure that they're giving you the latest data. Plus it's in an easier to consume format too!
Great idea. From my experience Excel is still the main data manipulation tool for many organisations (small business to large enterprise). Although it might be apparent for more technically minded users, I think an explanation about the security of the data would be beneficial for your target market.
I know you're still working things out, but I feel that your free tier is overly generous and your Business tier is a steal at $20. If it assuages a pain point for someone, that pain point is likely worth quite a bit more.
This seems like a nice layer between some data scientists that might be used to working with csv's or some subset of databases, and a dev team that happens to be using another subset of db's. Data scientists could throw some results into a csv and front end devs could quickly pull it in as a rough version of what the actual API would look like to get started on presentation of the data. First pass mockups could be done taking minimal time away from the engineering team, iterate these with stakeholders, and finally implement the final API with the fully fleshed out front end.
What makes this better than using the Google Docs API? I could have anyone write to a spreadsheet and in turn it would be updated when called on their API.
In fact I do that for many small business clients of mine which don't want to deal with databases for things like their product catalog and pricing lists.
Additionally you get version control, busier sites get the google doc scraped X times a minute as to not reach the request limit.
- Simplicity. It's fine for you to create an API via Google Docs, but I suspect it'd be tough for your (presumably) non-technical clients.
- Generated API docs
- Granular control of who sees what data and APIs
- Usage tracking (see who's using your APIs/data and how often)
- Easy integration for API clients: example code, no messing around with authenticating their Google account
I don't think you're wrong though: For publishers who already have their spreadsheets held in Google Docs and have setup an API, and are happy with that process, then there isn't a _huge_ benefit here.
That said, I've had quite a few emails overnight from people asking to support importing spreadsheets from Google Docs, so clearly they're missing something - I'll have to ask to find out whether it's something from my list above or something else.
The phrase "There's so many things that can go wrong with this" is really bothering me. I don't know why this mistake catches my attention, but it does. I probably speak that way but it should be written "There are" instead of "There is". Hopefully this sounds like creative criticism and not just bashing. I noticed that samcrawford is watching these comments.
Looks neat but can you add a github (or google/otheroauthprovider) login...the register page is way too daunting for me. Either that or provide an account-less mode for trying out the product before prompting signup..and even then i'd much rather not type into many fields when i can just auth with something else. Thanks again for the putting this out. look forward to playing with it :)
Curious, others are importing xls docs without issue, but yours is failing silently with return code 77 from libreoffice-headless (which is being used for the conversion). A quick Google shows I'm not alone here. Leave it with me, I'll reply here. In the meantime, feel free to convert to CSV or XLSX first and then import.
Honestly, I'd scrap everything up to $29/mth and change the pricing basis from MB and number of queries (people who use spreadsheets have no real understanding of this) to number of spreadsheets.
I remember working for Deutsche Bank 15yrs ago when one Excel spreadsheet could make them millions of £/day — don't be afraid to charge a decent amount! People who care about data, have spreadsheets, and need some interoperability will not baulk at $29, $50 or even $200/mth. And if they're giving you a decent income, they'll trust that you'll be around for longer.
Would you expect a bank (or accountant, or FMCG company) to trust a critical part of their process to a free or £12/mth service? Hell, no.
But perhaps part of the problem is that you've build a cool thing but don't know exactly who your customers should be. When you figure that out you'll be able to write more compelling copy and price it appropriately.
The only problem is that I'm almost sure that DB were making millions not thanks to the excel data per se but thanks to all the logic that was running inside/behind that Excel.
In this case, you can't "APIfy" it with a tool like this.
N.B. I'm not bashing sheetlabs, just saying that sometimes the most important part is not the numbers in the cell but how you create them
I wanted to encourage people here to give it a try and get some feedback. The splash page doesn't do a great job of selling it by itself; I think you need to try it to see the value. The Free tier allowances are probably a bit generous though.
It's worth noting that the costs for this really are tiny - just a couple of servers. I've done the sums, and even with the business tier costing $20, the profit margins are significant.
The biggest unknown is how much support each user will generate, and that's probably a good reason to raise the business price. Anyone who signs up before then will be offered the existing price of course.
Based in the UK. The site already does some work with geolocating the user (for giving localised pricing and also for inferring date formats when you upload spreadsheets), so I suppose I could localise spelling too ;)
In fact it appears more to be laziness on the part of the UK english. Whilst the 'ize' form is derived from the greek endings, certain english verbs had to end with 'ise'. As we were too lazy to remember which ended 'ize' or 'ise' we just took the pragmatic approach and used 'ise' version for all of them.
Neat. I'll be interested to see how access restriction by user is handled? Obscure header key or URL? Something authenticated? I guess I will have to sign up to find out. It doesn't appear to be documented publicly.
There's three access levels: public (anyone can access), authenticated (anyone authenticated user in your organisation can access), and private (only selected users can access).
If an API requires authentication, then you'll need to login to see documentation or query it.
There's a little about it on https://sheetlabs.com/#/docs at the bottom, but you're right that the docs need to be fleshed out more fully and linked from the front page.
Interesting, quite neat that you can share the data between organizations in a permissioned manner. Pricing is interesting, you may want to consider a usage based model rather than flat fee.
I actually think I'll be using this quite soon. I've also shown it to an excited PM, who thinks this could be useful for some clients that have been building reports from spreadsheets.
For me, I think there's a great use case for prototyping applications with a spreadsheet. I don't intend to build a service that exposes spreadsheet data as an external facing API.
Yes, certainly. Consider it added to the todo list. It wasn't a priority for a prototype, as the users I'm targeting are generally not Google Docs users anyway (at least in my own experience).
Interesting. I thought the opposite. Anyone who deals with APIs are likely gdoc users. Like us :) Anyway, adding google docs would open up a lot of cool things, like tapping into IFTTT recipes that already output there. You are providing the glue that removes a lot of grunt work.
This is awesome, btw. Could you talk about how you came about the idea?
Ah, agreed that the end-users of the APIs this builds would very likely also be Docs users. But the people who're turning their spreadsheets into APIs (i.e. the publishers) likely are not, in my experience.
Thanks for the compliment. As a developer working on a lot of systems that integrate service coverage data I'm constantly being sent spreadsheets that contain zip code / postcode level information, and I need to import this into my database or my client's databases. And normally my apps only want to lookup one or two values per day - but the third party is sending me their entire 100MB spreadsheet, as they don't have an API to publish it via. It's time consuming, error prone, and clunky. But they don't have the skill or resources to create an API, so I'm hoping something like this might remove some barriers.
Very interesting. So you may want to experiment with the messaging like "clients still doing things with excel spreadsheets?" for example, targeting developers who deal with excel dependent or decades old reporting clients. There are so many of those I'm sure.
There's two types of user here that go hand-in-hand:
The publisher, who cannot / will not create an API from their spreadsheets, but would like to (either to ease their own pain, or because their end users are asking for it, or because they don't want to share their entire dataset so often).
The consumer, who wants to access a little bit of their publisher's data without having to import spreadsheets en-masse regularly.
The publisher is the customer of the service ultimately, but the consumer will quite likely be the one driving the publisher to adopt it. Being self-critical, I'd say this makes it a bit of a tough sell (you're one step removed from the actual customer).
Edit: I should add that Sheetlabs uses loads of open source goodies under the hood. For converting inputs we use libreoffice for XLS to CSV and xslx2csv for XLSX files to CSV files.
They (Ycombinator) should implement 'mark as favorite'. There are so many similar tools included in the comments that I'm writing this comment just to have a quick shortcut to find the thread in future references.
This looks great. Now if you could only turn websites into a spreadsheet using http://scrape.ly and then turn it into an API using Sheetlabs, that would be awesome.
Particularly like the fact that REST APIs are pretty easy to start with providing GET access to resources, but get messy when you start doing POST, PUT, DELETE, PATCH etc. In this case, it's read-only by definition. That must make things so much easier. I can anticipate people asking for update access in future, but if you can get customers without it, I'd hold off with that for as long as possible.
One thing though - I think you should definitely raise your prices. 20Gb and 10 million queries for only €15 per month??!!