Changes in version 2
The entry point for Recipe Search API v2 is
The way pagination works in recipe search API has changed significantly from
version 1. The parameters
to are no longer supported. Instead,
responses will contain a pre-constructed URL for the next request in
_links.next.href. If this path is not present, then this was the last page and
there are no more results.
Each request now has to have a mandatory
type parameter with the value
This is added to enable us to add future extensions to the API without breaking
the existing integrations.
Obtaining information about specific recipe
r parameter is replaced with a URL path parameter. The search response now
contains pre-constructed URLs for each returned recipe in
If you have saved recipe URIs, which you were using with the
r parameter in
version 1, you would need to construct the new request manually.
A recipe URI has the form:
The part after
#recipe_ is called the hash. A request to v1 in the form of
will become the following request in v2:
The result of this request is just a single
Hit, instead of an array. Please
consult the Recipe Search API v2 documentation for details.
Filtering by cuisine, meal and dish type
Filtering by cuisine, meal and dish types has the same syntax as before, but
with stricter semantics. For example specifying a
will not return recipes from other “eastern” or other “European” cuisines.
Select result fields
Version 1 of the Recipe Search API returns the full information for each recipe. This make the result size large, which results in higher bandwith usage. Also, the processing of the response may require more CPU and RAM.
There are many use-cases where only a subset of the data is needed. In version 2
of the API one can use the
field parameters to specify which parts of the
results are needed. Please refer to the Recipe Search API v2 documentation for