Is it safe to assume that the developers have forgotten that there's a very big world beyond the US borders? The title doesn't say so, the blog post doesn't either, and the website makes no reference to the countries supported. But as the API doesn't take a country field, it's the only conclusion I can come to.
It's safer to assume that geo-based services posted to HN are likely US-centric and for good reasons (company is US-based, US is huge market, expanding outside the US is hard, etc).
As a side note, the carrier APIs make international rating easy. But, easy is a relative term, quite often there are a number of exceptions that make this area tricky.
The bottom of the page now has a "countries supported" text with an american flag. Hope this clears things up a little bit . If you are interested in getting notified when we support other countries i would be happy to email you.
IDEA: Stripe + EasyPost for an EBay that doesn't suck or price-gouge. You put stuff up for sale/auction, the payments go straight to your Stripe account and shipping is calculated/charged fairly. Emulate AirBnB for handling trust issues (reviews, email/phone verification and social graph connections).
I am curious how you guys are getting around the terms of use of the carriers especially address validation as it strictly forbids serving that information for others not associated with the developer key.
I would really like to know the answer to this. If they are just turning around and hitting USPS data for this, then last I checked, they are violating the TOS. Even if you have your own account, you can only use the address validation IF you are also going to ship to that address with USPS.
Perhaps they are using some other address validation service/data that allows for it.
Hmm... Does this validate that the address exists, or that an individual lives at that address? Just because someone has entered the incorrect address doesn't mean that the address doesn't exist.
To be clear, is this CASS/DPV-style validation? Is it certified CASS/DPV? If so, that would be awesome. Any info on usage limits for the free tier, etc? Can we use this for address verification only or is it required to purchase as well?
In the UK, sign-up forms that need addresses often let you enter a postcode then choose among a handful of buildings. This is usually based on Royal Mail 'PAF' data - for a price, they'll give you a CSV file of every address they deliver to.
Is there any US equivalent? What data do you use to back the address verification?
For testing - try to keep it reasonable (a few req/s).
If you are worried about exceeding our limits in production (via bulk or your site has that much traffic) feel free to email us: contact@geteasypost.com
It's nice to see startups tackling shipping APIs - they really are ugly.
What I'd really like to see is something that reaches down to the inventory level, I.e. I'm shipping these 5 SKUs, what's the best price among the carriers I support.
It's a complex problem (from experience) but it would provide real value to smaller shops who want to implement economy shipping but don't want to deal with all the APIs.
The idea is awesome, but handling products via a SKU is hard. For instance, if you had the SKU 517030000077284 (a Gibson Les Paul) how would you determine the package size that each customer individually uses? Or determine how much extra weight was added by packaging to keep the guitar safe?
I would love to solve this problem but it is definitely a hard one to solve.
Like I said, it's complex - for our internal solution we just queried for rates for all of our box sizes, and then our software suggests the cheapest it thinks will fit, but allows the warehouse guy to override it. It has a really simple formula for "learning" when he chooses something different.
A general solution would be much harder, but if it had existed we would have forked over money without too much thought.
I doubt it. Carrier terms of service make the SaaS model for this difficult if not impossible. I also don't understand why anyone would pay a percentage per label when the carriers offer free APIs. Sure the APIs are a pain but there are good libraries out there for them.
I could see people using this to get up and running quickly, but then flushing out their system to integrate directly with carriers once size dictates.
Example: DailyCred lets you drop in authentication on your site, but when you get big enough (or have the time resources), you can dump out the bcrypted password hashes into your own built-out auth system.
MVP/Prototype->Iterate->Grow. These services that are reducing pain points let you get the first parts done fast, so you can get to the growth stage faster.
I think you should have a form where users can try out your address checks. This is just so devs can quickly make sure if you know the difference between good and a bad address before they try out the api.
This is because their demo uses https, as recommended in their documentation ("We suggest that you make API requests over HTTPS..."). But, if you switch to using the http protocol, the request will return a response correctly. It's a bug.
Also interesting because their website redirects http requests to the https protocol (eg. http://geteasypost.com/docs).