Empowering Restaurants through Integration

  1. Grubhub Developers
  2. Order Taking
  3. Using the API
Follow

 

Introduction to the Order Taking API

Welcome to the Grubhub order-taking API! This API lets you build systems that allow diners to order menu items from restaurants in the Grubhub database, fulfilled automatically as a delivery or pickup order.

This API documentation is divided into two sections: Using the API, which covers specific topics about how to use the API, and API Specification, which details the inputs, outputs, and syntax for the Grubhub endpoints.

To get started on how building an ordering system with the Grubhub API works, check out the Getting Started Guide. This provides a walkthrough of the processes, endpoints, and users experiences that you’ll need to consider when building an ordering system. It’s quick and dirty, so it’ll give you the basics, but it won’t be everything. If you need something else not covered, talk to your account representatives, and we’ll see if it’s something we want to add to the documentation library.

Other things to note:

The Data Feed

The API does not provide restaurant ID search capabilities. You can return information for individual restaurants, but the IDs of those restaurants should be included in the data feed from Grubhub.

Your data feed will provide much of the same information as included in the restaurant data definition.

Testing

In building your application, you’ll need a way to test it without spending a fortune on delivered food.

If you received a pre-production server address as part of your contract, specify that as the host before any your endpoint requests. It should have similar data, though no orders will be sent to actual restaurants.

Additionally, you may want to use the following test restaurants (warning, they may be silly):

These restaurants, as well as those located at 6 Old Mill St, Alamo, NV 89001, are not real restaurants, though they have complete and testable data.

For credit cards, check with your Braintree account representatives for access to test card information.

Common HTML Status Codes

In the API Specification, we haven’t documented every single HTML status code possible, as many of them are common to RESTful APIs. Here are the ones that come up in our APIs and how you can address them. 

200 OK

Request completed successfully. This probably returns a JSON response payload in the body.

201 Created

The requested resource was created. This may return a JSON object in the response body.

204 No Content

The request completed successfully, and no JSON object will be returned in the response body intentionally.

400 Bad request

A field, either at the top level or nested within an array, has the wrong data type. For example, passing “abcde” in an integer field. The response body will detail what field is malformed.

415 Unsupported media type

Usually indicates that the request indicated the wrong media type in the header. For example, if you send them as XML when the Grubhub API expects JSON.

422 Unprocessable Entity (WebDAV)

This indicates that one or more of the fields passed could not be used. It could mean that a required field is missing, a value is outside the bounds of what’s acceptable, or an array is the wrong size. The response body will detail what needs to be fixed in the request.