Medusa V2 Store API Reference
This API reference includes Medusa v2's Store APIs, which are REST APIs exposed by the Medusa application. They are used to create a storefront for your commerce store, such as a webshop or a commerce mobile app.
All API Routes are prefixed with /store. So, during development, the API Routes will be available under the path http://localhost:9000/store. For production, replace http://localhost:9000 with your Medusa application URL.
Just Getting Started?
Check out the Medusa v2 Documentation.
Medusa JS SDK
To use Medusa's JS SDK library, install the following packages in your project (not required for admin customizations):
Learn more about the JS SDK and how to configure it in this documentation.
Download Full Reference#
Download this reference as an OpenApi YAML file. You can import this file to tools like Postman and start sending requests directly to your Medusa application.
Authentication#
There are two ways to send authenticated requests to the Medusa application: Using a JWT token or using a Cookie Session ID.
1. Bearer Authorization with JWT Tokens#
Use a JWT token in a request's bearer authorization header to send authenticated requests. Authentication state is managed by the client, which is ideal for Jamstack applications and mobile applications.
How to Obtain the JWT Token
To obtain a JWT token, send a request to the authentication route passing it the customer's email and password in the request body.
If authenticated successfully, an object is returned in the response with the property token being the JWT token.
How to Use the JWT Token
To use the JWT token, pass it in the authorization bearer header.
If you're using the JS SDK, the login method automatically sets the token for you and passes it to subsequent requests. You can also set the token manually using the client.setToken method.
auth.type configuration of the JS SDK to jwt to use the JWT token. Learn more in the JS SDK configurations.2. Cookie Session ID#
When you authenticate a customer and create a cookie session ID for them, the cookie session ID is passed automatically when sending the request from the browser, or with tools like Postman.
How to Obtain the Cookie Session#
To obtain a cookie session ID, you must have a JWT token for bearer authentication.
Then, if you're using the JS SDK, make sure the auth.type configuration is set to session, as explained in the JS SDK configurations guide. The auth.login method will handle setting the session cookie and passing it in subsequent requests.
If you're not using the JS SDK, send a request to the session authentication API route. To view the cookie session ID, pass the -v option to the curl command.
If you send the cURL request, the headers will be logged in the terminal as well as the response. You
should find in the headers a Cookie header.
How to Use the Cookie Session ID in cURL
If you're using the JS SDK, it will pass the cookie session with every request automatically after you use the auth.login method.
If you're not using the JS SDK, copy the value after connect.sid (without the ; at the end) and pass
it as a cookie in subsequent requests.
Including Credentials in the Fetch API
If you're sending requests using JavaScript's Fetch API, you must pass the credentials option
with the value include to all the requests you're sending.
Publishable API Key#
You must pass a publishable API key in the header of your requests to the store API routes.
Publishable API Keys sets the scope of your request to one or more sales channels. This ensures you only retrieve products available in the publishable API key's sales channels, retrieve correct inventory details, and associate placed orders with the specified sales channel.
How to Create a Publishable API Key#
Create a publishable API key either using the admin REST APIs, or using the Medusa Admin.
How to Use a Publishable API Key#
If you're using the JS SDK, set the publishable API key in the JS SDK's configurations.
If you're not using the JS SDK, pass the publishable API key in the header x-publishable-api-key in all your requests to the store APIs.
Where {your_publishable_api_key} is the token of the publishable API key. When using the JS SDK, set the value as an environment variable.
HTTP Compression#
If you've enabled HTTP Compression in your Medusa configurations, and you
want to disable it for some requests, you can pass the x-no-compression
header in your requests.
If you're using the JS SDK, every method accepts a headers parameter as the last parameter. You can pass in it custom headers, including the x-no-compression header.
Select Fields and Relations#
Many API Routes accept a fields query that allows you to select which fields and relations should be returned in a record.
Fields and relations are separated by a comma ,.
This returns only the title and handle fields of a product.
Fields Operator#
By default, only the selected fields and relations are returned in the response.
Before every field or relation, you can pass one of the following operators to change the default behavior:
+: Add the field to the fields returned by default. For example,+titlereturns thetitlefield along with the fields returned by default.-: Remove the field from the fields returned by default. For example,-titleremoves thetitlefield from the fields returned by default.
Select Relations#
To select a relation, pass to fields the relation name prefixed by *.
This returns the variants of each product.
Select Fields in a Relation#
The * prefix selects all fields of the relation's data model.
To select a specific field, pass a .<field> suffix instead of the * prefix. For example, variants.title.
To specify multiple fields, pass each of the fields with the <relation>.<field> format, separated by a comma.
This returns the variants of each product, but the variants only have their id, title, and sku fields. The id is always included.
Query Parameter Types#
This section covers how to pass some common data types as query parameters.
This is useful if you're sending requests to the API Routes using cURL or Postman.
Strings#
You can pass a string value in the form of <parameter_name>=<value>.
If the string has any characters other than letters and numbers, you must
encode them. For example, if the string has spaces, you can encode the space with + or
%20.
When using the JS SDK, you can pass the string directly to the query parameter. The JS SDK will encode the string for you.
You can use tools like this one to learn how a value can be encoded.
Integers#
You can pass an integer value in the form of <parameter_name>=<value>.
Boolean#
You can pass a boolean value in the form of <parameter_name>=<value>.
Date and DateTime#
You can pass a date value in the form <parameter_name>=<value>. The date
must be in the format YYYY-MM-DD.
You can also pass the time using the format YYYY-MM-DDTHH:MM:SSZ. Please
note that the T and Z here are fixed.
Array#
Array filters can be passed either as:
<parameter_name>[]=<value1>,<value2>, separating the values by a comma.<parameter_name>[]=<value1>&<parameter_name>[]=<value2>, passing each value as a separate query parameter. You can also specify the index of each parameter in the brackets<parameter_name>[0]=<value>.
When using the JS SDK, you can pass the array directly to the query parameter. The JS SDK will handle the rest.
Note that the -g parameter passed to curl disables errors being thrown
for using the brackets. Read more
here.
Object#
Object parameters must be passed as separate query parameters in the form
<parameter_name>[<key>]=<value>.
When using the JS SDK, you can pass the object directly to the query parameter. The JS SDK will handle the rest.
limit is used to specify the maximum number of items to be returned in the response. offset is used to specify how many items to skip before returning the resulting records.
Use the offset query parameter to change between pages. For example, if the limit is 50, at page 1 the offset should be 0; at page 2 the offset should be 50, and so on.
Response Fields#
In the response of listing API Routes, aside from the records retrieved, there are three pagination-related fields returned:
limit: the maximum number of items that can be returned in the response.offset: the number of items that were skipped before the records in the result.count: the total number of available items of this data model. It can be used to determine how many pages are there.
For example, if the count is 100 and the limit is 50, divide the
count by the limit to get the number of pages: 100/50 = 2 pages.
Sort Order#
The order field (available on API Routes that support pagination) allows you to
sort the retrieved items by a field of that item.
This sorts the products by their created_at field in the ascending order.
By default, the sort direction is ascending. To change it to
descending, pass a dash (-) before the field name.
This sorts the products by their created_at field in the descending order.
Workflows#
While browsing this reference, you'll find some API routes mention what workflow is used in them.
If you click on the workflow, you'll view a reference of that workflow, including its hooks.
This is useful if you want to extend an API route and pass additional data or perform custom actions.
Refer to this guide to find an example of extending an API route.
Auth
Currencies
Related guide: How to retrieve product variant prices in a storefront.
Customers
Related guide: How to implement customer account functionalities in a storefront.
Orders
Payment Collections
Related guide: How to implement payment during checkout.
Product Categories
Related guide: How to list product categories in a storefront.
Product Tags
Product Types
Products
Related guide: How to list products, get their prices, and more in a storefront.
Regions
Related guide: How to retrieve and store selected region in a storefront.