I have been building an inventory and order management system for my wife’s home business recently. This system relies heavily upon data retrieved from outside sources, thus it uses APIs to fetch this data. Notably it uses APIs from Paypal, USPS.com (US Postal Service,) and Etsy.com.
This past week has been fraught with frustration as I have worked with these APIs, and it has only emphasized what has long been a pet peeve of mine when it comes to so-called “sandbox servers.” Not putting any useful data on your stupid test server!
Oddly enough, and despite all of my expectations going into this project, Paypal has proven to be the best to work with. Of course I have long experience with Paypal as I deal with their systems a lot at work, though using their RESTful API is new to me. And most of what I have been doing is POST (ie sending data instead of reading data) which makes it inherently simpler. But their documentation provides very clear examples of what to send and what to expect in return.
USPS on the other hand, is the complete opposite. The documentation available is rather sparse, but gives the needed information (along with severe reminders not to send hazardous materials through the mail!) The real frustration came along with the enforcement of their API developer policy that restricts you to their sandbox server until you prove to them that you know what you are doing and then contact their support via email to request access to the live server.
I had acquired an SDK containing some pre-written API integration classes that I had planned on using. So I configured it with the access credentials I had been provided, integrated it into my form, and input my address expecting to get my zip code back from the API. Instead, it returned the following:
The information you requested was not found on this server.
Okay, I live in The Middle of Nowhere, UT; perhaps the White House’s address would return something? Alas, that address was not found on the server either. Nor was that of the USPS headquarters in Washington DC. I tried for a good 30 minutes, but couldn’t find a single address that was found on that server.
I gave up…blasted useless sandbox server! It was time to just ask for access to the live server and go from there. I wasn’t developing the software myself exactly, I was using something someone else already wrote and used. So I emailed the USPS and asked for access, and received this reply:
We are unable to move your account to the production server until two valid test requests have been received.
Seriously? I had to convince them that my development was complete since I was using third-party software and therefore testing was pointless, that even the testing I tried didn’t work since they didn’t have any available data on their stupid sandbox server!
Moving on to the Etsy APIs, they had a somewhat similar policy. For each “app” you create, credentials are generated which grant oauth access only to their sandbox server by default. It does give what they call “production API” access to the live server, which is essentially read-only non-authenticated access immediately….but that is mostly useless for my purposes. I really need full access to all of the data on the live server. However:
You should expect the approval process to take 1-2 weeks.
Okay, well, they have a sandbox server which I can develop on, so no problem, right? Except for the fact that there isn’t any useful data on it! It works just fine for writing to, and it’s great for sending listings and other methods such as that which would normally incur a charge when run on the live server. But in my case I am trying to simply pull data from a live store.
As I had when working with the USPS API, I assumed there would be some default data to work with. In the documentation it suggests replacing the username in a request with “EtsyStore,” which worked great when using the production API on the live server. However, when I tried this using the sandbox server, can you guess what happened?
failed (404): ‘EtsyStore’ is not a valid user name.
Can you understand my frustration? I was using the very API they used in their documentation, getUser, and the user they suggested, and it said it was not valid! It worked great on the live server, so obviously the API is correct and my code utilizing it is functioning properly.
I’ve used eNom’s APIs quite a bit; and as much frustration as I’ve had working with eNom as a whole, I can say that they do this part properly. They provide a test server that seems to be a complete mirror of their live environment. It doesn’t contain all of the live data on my account of course; but it provides a full front-end in which I can create everything I need to do to mirror the setup that I am working with. It has saved so much valuable time that I will sing their praises on this aspect until I grow hoarse.
Knowing the exact format of the data which an API returns is crucial to a developer. A single documented example often is not enough, especially when you are testing; there is nothing to compare to having a functioning example to work with and seeing your parser take shape!