Tag: api

Posted on

MageSpeedTest.com: New locations, Magento Extension, REST API, Featured Host and Pricing

Way back in 2010 I set up a quick little wrapper around siege for testing Magento stores and for the last nearly 2 years I’ve added features such as multiple data centers, premium subscriptions, monitoring alerts, and automated host comparisons. In this blog post I’ll walk you through an update on the new features and improvements to MageSpeedTest.com over the last few months.

I’m really happy with the site and how it helps users identify and improve Magento performance. I often see test results coming through in the order of 2-3 transactions per second and >5s per transaction. Identifying these sort of slow stores early is important – customers are simply not going to wait at least 5 seconds to see a product page these days.

At the opposite end of the performance spectrum I see public tests coming through with incredible performance profiles. For these developers and server admins it’s a way to consistently test server tweaks and tuning to get the absolute best customer experience.

In this post I wanted to quickly cover my latest Magento Speed Test changes. It’s a big update because I haven’t posted anything in a while.

Here’s the cliff notes:

  • New Locations: Japan, South America and Australia
  • A Magento Extension to make testing easy (and more soon!)
  • A REST API for accessing your monitoring results
  • A pricing update, $5 up to $9 per month
  • Featured Magento hosts
  • SSL support – test https:// sites

For more information on these items, please read on.
Continue reading MageSpeedTest.com: New locations, Magento Extension, REST API, Featured Host and Pricing

Posted on

Magento Imagine 2012: Making the most of APIs

Just finished up with my API presentation at Magento Imagine 2012, thanks to those who came along, and for the interesting questions and discussions afterwards. Great conference so far and looking forward to more interesting tech topics.

As promised here are the PDF slides, links to code examples and the blog post I mentioned that runs through the new Magento 1.7 REST API and oAuth. If any one has some comments or questions please do not hesitate to ask.

Update: Videos of all the tech talks are up on the Imagine site, here’s mine.

Also, if you’re a merchant, or an agency with merchants on board who might be interested, please check out our mobile sales dashboard, OrderPipe.com

Thanks to everyone who twittered and took pictures during the talk, given the temporal nature of twitter, I’ll post a few tweets below for the archive.


Posted on

Introduction to the Magento REST APIs with oAuth in Version 1.7

The latest version of Magento (1.7rc1 right now) has support for oAuth authenticated REST APIs, yippee! In this post I’m going to run through the technical aspects of setting up the Magento oAuth and making your first Magento REST API call.

I’m presenting on APIs during the technology track at the Magento Imagine conference on Tuesday (If you’re reading this, and you’re at the conference, I hope to see you there!). In my talk I’ll cover interesting uses and benefits of the REST API but won’t have time for a big fully worked example. This post details the finer points of actually using these APIs which is a bit too low-level to cover, so this will be extra-for-experts homework for those that want to have a play around with REST after the talk.

There are basically 3 steps to running your first REST API call in Magento.
Continue reading Introduction to the Magento REST APIs with oAuth in Version 1.7

Posted on

Shipwire Tracking API – Mapping API carrier codes in Tracking updates within Magento

This is just a quick note that might save someone some time/effort. I’ve been working with the Shipwire Tracking API and Magento lately and although I think their API is good, it’s lacking in certain areas. Namely utility for customer facing applications.

The Shipwire tracking API returns short codes for carrier and service, which doesn’t really make it very useful for customer facing communication, nobody wants to know their parcel shipped on “RM FCLR“, instead of Royal Mail First Class Large Letter – Recorded Signed For. I contacted Shipwire support about it and they provided the comprehensive list of carriers and codes (thanks Gene!).
Continue reading Shipwire Tracking API – Mapping API carrier codes in Tracking updates within Magento

Posted on

Magento Google Base error: Expected response code 200, got 403 Service forbidden: Account not registered for Google Base

After some initial Google Base problems with Magento 1.3.2.1, I thought everything was going to be fine, only to get whacked with this error: Expected response code 200, got 403 Service forbidden: Account not registered for Google Base. I checked and checked again that my email/password was right, and that the Google account was registered for Google Base.

There wasn’t much help surfacing on Google for it, so I thought now that I have sifted through everything and looked at various sources, I’d compile a bit of an explanation and help guide for it. Please note this only affects 1.3.2.1, it is fixed in the newer versions of Magento, so unless you are wed to your current version, upgrade!

I posted a forum message on the Google Base boards and got this helpful reply:

  • verify the application is not exceeding the api
    limits of approximately 5 requests per second;
  • verify the proper uri is being used for the request.
  • verify all the required attributes and proper values
    are being used for the item-type being inserted —
    check that all the rules for the item-type are being met.

Given my products were not anything special, I doubted the last option. Also given others were reporting success with the Magento Google Base capability (once the initial problem was fixed), I assumed it wasn’t the 5 requests per second problem either. So what was wrong with the request URI?

Well, to cut a long story short, it seems that my problem was due to the account being used for Google Base, also being a Google Apps account. If you’re interested in the details check out the login options for the Google Account API. The hosted Google Apps account did not have Google Base, but the Google account (with the same email and password) did. The login was succeeding, but then the account that was logged-in did not have access to Google Base!

The fix is to tell the GClient API to use the Google account only, not the HOSTED_OR_GOOGLE default. I found others have suggested this fix (or the workaround of using a non-Google Apps account) here.

The gist of it is to change this function call by adding two extra parameters: app\code\core\Mage\GoogleBase\Model\Service.php on line 49. The two parameters to add are: Zend_Gdata_ClientLogin::CLIENTLOGIN_URI, 'GOOGLE' as shown below.

$client = Zend_Gdata_ClientLogin::getHttpClient($user, $pass, Zend_Gdata_Gbase::AUTH_SERVICE_NAME, null, '', $loginToken, $loginCaptcha, Zend_Gdata_ClientLogin::CLIENTLOGIN_URI, 'GOOGLE');

That fixed the problem for me, now I just have to figure out which of the required Google Base attributes I’m missing!