914d773d3a
* initialized next.js project * finished markdown sections * added operation schema component * change page metadata * eslint fixes * fixes related to deployment * added response schema * resolve max stack issue * support for different property types * added support for property types * added loading for components * added more loading * type fixes * added oneOf type * removed console * fix replace with push * refactored everything * use static content for description * fixes and improvements * added code examples section * fix path name * optimizations * fixed tag navigation * add support for admin and store references * general enhancements * optimizations and fixes * fixes and enhancements * added search bar * loading enhancements * added loading * added code blocks * added margin top * add empty response text * fixed oneOf parameters * added path and query parameters * general fixes * added base path env variable * small fix for arrays * enhancements * design enhancements * general enhancements * fix isRequired * added enum values * enhancements * general fixes * general fixes * changed oas generation script * additions to the introduction section * added copy button for code + other enhancements * fix response code block * fix metadata * formatted store introduction * move sidebar logic to Tags component * added test env variables * fix code block bug * added loading animation * added expand param + loading * enhance operation loading * made responsive + improvements * added loading provider * fixed loading * adjustments for small devices * added sidebar label for endpoints * added feedback component * fixed analytics * general fixes * listen to scroll for other headings * added sample env file * update api ref files + support new fields * fix for external docs link * added new sections * fix last item in sidebar not showing * move docs content to www/docs * change redirect url * revert change * resolve build errors * configure rewrites * changed to environment variable url * revert changing environment variable name * add environment variable for API path * fix links * fix tailwind settings * remove vercel file * reconfigured api route * move api page under api * fix page metadata * fix external link in navigation bar * update api spec * updated api specs * fixed google lint error * add max-height on request samples * add padding before loading * fix for one of name * fix undefined types * general fixes * remove response schema example * redesigned navigation bar * redesigned sidebar * fixed up paddings * added feedback component + report issue * fixed up typography, padding, and general styling * redesigned code blocks * optimization * added error timeout * fixes * added indexing with algolia + fixes * fix errors with algolia script * redesign operation sections * fix heading scroll * design fixes * fix padding * fix padding + scroll issues * fix scroll issues * improve scroll performance * fixes for safari * optimization and fixes * fixes to docs + details animation * padding fixes for code block * added tab animation * fixed incorrect link * added selection styling * fix lint errors * redesigned details component * added detailed feedback form * api reference fixes * fix tabs * upgrade + fixes * updated documentation links * optimizations to sidebar items * fix spacing in sidebar item * optimizations and fixes * fix endpoint path styling * remove margin * final fixes * change margin on small devices * generated OAS * fixes for mobile * added feedback modal * optimize dark mode button * fixed color mode useeffect * minimize dom size * use new style system * radius and spacing design system * design fixes * fix eslint errors * added meta files * change cron schedule * fix docusaurus configurations * added operating system to feedback data * change content directory name * fixes to contribution guidelines * revert renaming content * added api-reference to documentation workflow * fixes for search * added dark mode + fixes * oas fixes * handle bugs * added code examples for clients * changed tooltip text * change authentication to card * change page title based on selected section * redesigned mobile navbar * fix icon colors * fix key colors * fix medusa-js installation command * change external regex in algolia * change changeset * fix padding on mobile * fix hydration error * update depedencies
454 lines
21 KiB
YAML
454 lines
21 KiB
YAML
openapi: 3.0.0
|
|
info:
|
|
version: 1.0.0
|
|
title: Medusa Admin API
|
|
license:
|
|
name: MIT
|
|
url: https://github.com/medusajs/medusa/blob/master/LICENSE
|
|
tags:
|
|
- name: Apps Oauth
|
|
description: |
|
|
Some plugins may require to authenticate with third-party services and store authentication details, such as the authentication token. To do that, they can create an Oauth provider within the plugin that handles the authentication.
|
|
The Apps Oauth endpoints allows admins to manage and generate token for an app using its oauth provider.
|
|
- name: Auth
|
|
description: |
|
|
Authentication endpoints allow admin users to manage their session, such as login or log out.
|
|
When an admin user is logged in, the cookie header is set indicating the admin's login session.
|
|
externalDocs:
|
|
description: How to implement user profiles
|
|
url: https://docs.medusajs.com/modules/users/admin/manage-profile
|
|
- name: Batch Jobs
|
|
description: |
|
|
A batch job is a task that is performed by the Medusa backend asynchronusly. For example, the Import Product feature is implemented using batch jobs.
|
|
Batch Job endpoints allows admins to manage the batch jobs and their state.
|
|
externalDocs:
|
|
description: How to import products
|
|
url: https://docs.medusajs.com/modules/products/admin/import-products
|
|
- name: Currencies
|
|
description: |
|
|
A store can use unlimited currencies, and each region must be associated with at least one currency.
|
|
Currencies are defined within the Medusa backend. Currency endpoints allow admins to list and update currencies.
|
|
externalDocs:
|
|
description: How to manage currencies
|
|
url: https://docs.medusajs.com/modules/regions-and-currencies/admin/manage-currencies
|
|
- name: Customers
|
|
description: |
|
|
Customers can either be created when they register through the Store APIs, or created by the admin using the Admin APIs.
|
|
externalDocs:
|
|
description: How to manage customers
|
|
url: https://docs.medusajs.com/modules/customers/admin/manage-customers
|
|
- name: Customer Groups
|
|
description: |
|
|
Customer Groups can be used to organize customers that share similar data or attributes into dedicated groups.
|
|
This can be useful for different purposes such as setting a different price for a specific customer group.
|
|
externalDocs:
|
|
description: How to manage customer groups
|
|
url: https://docs.medusajs.com/modules/customers/admin/manage-customer-groups
|
|
- name: Discounts
|
|
description: |
|
|
Admins can create discounts with conditions and rules, providing them with advanced settings for variety of cases.
|
|
The Discount endpoints can be used to manage discounts, their conditions, resources, and more.
|
|
externalDocs:
|
|
description: How to manage discounts
|
|
url: https://docs.medusajs.com/modules/discounts/admin/manage-discounts
|
|
- name: Draft Orders
|
|
description: |
|
|
A draft order is an order created manually by the admin. It allows admins to create orders without direct involvement from the customer.
|
|
externalDocs:
|
|
description: How to manage draft orders
|
|
url: https://docs.medusajs.com/modules/orders/admin/manage-draft-orders
|
|
- name: Gift Cards
|
|
description: |
|
|
Admins can create gift cards and send them directly to customers, specifying options like their balance, region, and more.
|
|
These gift cards are different than the saleable gift cards in a store, which are created and managed through Product endpoints.
|
|
externalDocs:
|
|
description: How to manage gift cards
|
|
url: https://docs.medusajs.com/modules/gift-cards/admin/manage-gift-cards#manage-custom-gift-cards
|
|
- name: Inventory Items
|
|
description: |
|
|
Inventory items, provided by the [Inventory Module](https://docs.medusajs.com/modules/multiwarehouse/inventory-module), can be used to manage the inventory of saleable items in your store.
|
|
externalDocs:
|
|
description: How to manage inventory items
|
|
url: https://docs.medusajs.com/modules/multiwarehouse/admin/manage-inventory-items
|
|
- name: Invites
|
|
description: |
|
|
An admin can invite new users to manage their team. This would allow new users to authenticate as admins and perform admin functionalities.
|
|
externalDocs:
|
|
description: How to manage invites
|
|
url: https://docs.medusajs.com/modules/users/admin/manage-invites
|
|
- name: Notes
|
|
description: |
|
|
Notes are created by admins and can be associated with any resource. For example, an admin can add a note to an order for additional details or remarks.
|
|
- name: Notifications
|
|
description: |
|
|
Notifications are sent to customers to inform them of new updates. For example, a notification can be sent to the customer when their order is place or its state is updated.
|
|
The notification's type, such as an email or SMS, is determined by the notification provider installed on the Medusa backend.
|
|
- name: Orders
|
|
description: |
|
|
Orders are purchases made by customers, typically through a storefront using the Store API. Draft orders created by the admin are also transformed to an Order once the payment is captured.
|
|
Managing orders include managing fulfillment, payment, claims, reservations, and more.
|
|
externalDocs:
|
|
description: How to manage orders
|
|
url: https://docs.medusajs.com/modules/orders/admin/manage-orders
|
|
- name: Order Edits
|
|
description: |
|
|
An admin can edit an order to remove, add, or update an item's quantity. When an admin edits an order, they're stored as an `OrderEdit`.
|
|
externalDocs:
|
|
description: How to edit an order
|
|
url: https://docs.medusajs.com/modules/orders/admin/edit-order
|
|
- name: Payments
|
|
description: |
|
|
A payment can be related to an order, swap, return, or more. It can be captured or refunded.
|
|
- name: Payment Collections
|
|
description: |
|
|
A payment collection is useful for managing additional payments, such as for Order Edits, or installment payments.
|
|
- name: Price Lists
|
|
description: |
|
|
A price list are special prices applied to products based on a set of conditions, such as customer group.
|
|
externalDocs:
|
|
description: How to manage price lists
|
|
url: https://docs.medusajs.com/modules/price-lists/admin/manage-price-lists
|
|
- name: Products
|
|
description: |
|
|
Products are saleable items in a store. This also includes [saleable gift cards](https://docs.medusajs.com/modules/gift-cards/admin/manage-gift-cards#manage-gift-card-product) in a store.
|
|
externalDocs:
|
|
description: How to manage products
|
|
url: https://docs.medusajs.com/modules/products/admin/manage-products
|
|
- name: Product Categories
|
|
description: |
|
|
Products can be categoriezed into categories. A product can be added into more than one category.
|
|
externalDocs:
|
|
description: How to manage product categories
|
|
url: https://docs.medusajs.com/modules/products/admin/manage-categories
|
|
- name: Product Collections
|
|
description: |
|
|
A product collection is used to organize products for different purposes such as marketing or discount purposes. For example, you can create a Summer Collection.
|
|
- name: Product Tags
|
|
description: |
|
|
Product tags are string values created when you create or update a product with a new tag.
|
|
Products can have more than one tag, and products can share tags. This allows admins to associate products to similar tags that can be used to filter products.
|
|
- name: Product Types
|
|
description: |
|
|
Product types are string values created when you create or update a product with a new type.
|
|
Products can have one type, and products can share types. This allows admins to associate products with a type that can be used to filter products.
|
|
- name: Product Variants
|
|
description: |
|
|
Product variants are the actual salable item in your store. Each variant is a combination of the different option values available on the product.
|
|
Product variants can be managed through the Products endpoints.
|
|
externalDocs:
|
|
description: How to manage product variants
|
|
url: https://docs.medusajs.com/modules/products/admin/manage-products#manage-product-variants
|
|
- name: Publishable API Keys
|
|
description: |
|
|
Publishable API Keys can be used to scope Store API calls with an API key, determining what resources are retrieved when querying the API.
|
|
For example, a publishable API key can be associated with one or more sales channels. When it is passed in the header of a request to the List Product store endpoint,
|
|
the sales channels are inferred from the key and only products associated with those sales channels are retrieved.
|
|
Admins can manage publishable API keys and their associated resources. Currently, only Sales Channels are supported as a resource.
|
|
externalDocs:
|
|
description: How to manage publishable API keys
|
|
url: https://docs.medusajs.com/development/publishable-api-keys/admin/manage-publishable-api-keys
|
|
- name: Reservations
|
|
description: |
|
|
Reservations, provided by the [Inventory Module](https://docs.medusajs.com/modules/multiwarehouse/inventory-module), are quantities of an item that are reserved, typically when an order is placed but not yet fulfilled.
|
|
Reservations can be associated with any resources, but commonly with line items of an order.
|
|
externalDocs:
|
|
description: How to manage item allocations in orders
|
|
url: https://docs.medusajs.com/modules/multiwarehouse/admin/manage-item-allocations-in-orders
|
|
- name: Regions
|
|
description: |
|
|
Regions are different countries or geographical regions that the commerce store serves customers in.
|
|
Admins can manage these regions, their providers, and more.
|
|
externalDocs:
|
|
description: How to manage regions
|
|
url: https://docs.medusajs.com/modules/regions-and-currencies/admin/manage-regions
|
|
- name: Return Reasons
|
|
description: |
|
|
Return reasons are key-value pairs that are used to specify why an order return is being created.
|
|
Admins can manage available return reasons, and they can be used by both admins and customers when creating a return.
|
|
externalDocs:
|
|
description: How to manage return reasons
|
|
url: https://docs.medusajs.com/modules/orders/admin/manage-returns#manage-return-reasons
|
|
- name: Returns
|
|
description: |
|
|
A return can be created by a customer or an admin to return items in an order.
|
|
Admins can manage these returns and change their state.
|
|
externalDocs:
|
|
description: How to manage returns
|
|
url: https://docs.medusajs.com/modules/orders/admin/manage-returns
|
|
- name: Sales Channels
|
|
description: |
|
|
A sales channel indicates a channel where products can be sold in. For example, a webshop or a mobile app.
|
|
Admins can manage sales channels and the products available in them.
|
|
externalDocs:
|
|
description: How to manage sales channels
|
|
url: https://docs.medusajs.com/modules/sales-channels/admin/manage
|
|
- name: Shipping Options
|
|
description: |
|
|
A shipping option is used to define the available shipping methods during checkout or when creating a return.
|
|
Admins can create an unlimited number of shipping options, each associated with a shipping profile and fulfillment provider, among other resources.
|
|
externalDocs:
|
|
description: Shipping Option architecture
|
|
url: https://docs.medusajs.com/modules/carts-and-checkout/shipping#shipping-option
|
|
- name: Shipping Profiles
|
|
description: |
|
|
A shipping profile is used to group products that can be shipped in the same manner.
|
|
They are created by the admin and they're not associated with a fulfillment provider.
|
|
externalDocs:
|
|
description: Shipping Option architecture
|
|
url: https://docs.medusajs.com/modules/carts-and-checkout/shipping#shipping-profile
|
|
- name: Stock Locations
|
|
description: |
|
|
A stock location, provided by the [Stock Location module](https://docs.medusajs.com/modules/multiwarehouse/stock-location-module), indicates a physical address that stock-kept items, such as physical products, can be stored in.
|
|
An admin can create and manage available stock locations.
|
|
externalDocs:
|
|
description: How to manage stock locations.
|
|
url: https://docs.medusajs.com/modules/multiwarehouse/admin/manage-stock-locations
|
|
- name: Store
|
|
description: |
|
|
A store indicates the general configurations and details about the commerce store. By default, there's only one store in the Medusa backend.
|
|
Admins can manage the store and its details or configurations.
|
|
- name: Swaps
|
|
description: |
|
|
A swap is created by a customer or an admin to exchange an item with a new one.
|
|
Creating a swap implicitely includes creating a return for the item being exchanged.
|
|
externalDocs:
|
|
description: How to manage swaps
|
|
url: https://docs.medusajs.com/modules/orders/admin/manage-swaps
|
|
- name: Tax Rates
|
|
description: |
|
|
Each region has at least a default tax rate. Admins can create and manage additional tax rates that can be applied for certain conditions, such as for specific product types.
|
|
externalDocs:
|
|
description: How to manage tax rates
|
|
url: https://docs.medusajs.com/modules/taxes/admin/manage-tax-rates
|
|
- name: Uploads
|
|
description: |
|
|
The upload endpoints are used to upload any type of resources. For example, they can be used to upload CSV files that are used to import products into the store.
|
|
externalDocs:
|
|
description: How to upload CSV file when importing a product.
|
|
url: https://docs.medusajs.com/modules/products/admin/import-products#1-upload-csv-file
|
|
- name: Users
|
|
description: |
|
|
A store can have more than one user, each having the same privileges. Admins can manage users, their passwords, and more.
|
|
externalDocs:
|
|
description: How to manage users
|
|
url: https://docs.medusajs.com/modules/users/admin/manage-users
|
|
servers:
|
|
- url: https://api.medusa-commerce.com
|
|
paths: { }
|
|
components:
|
|
responses:
|
|
default_error:
|
|
description: Default Error
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: "#/components/schemas/Error"
|
|
example:
|
|
code: "unknown_error"
|
|
message: "An unknown error occurred."
|
|
type: "unknown_error"
|
|
invalid_state_error:
|
|
description: Invalid State Error
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: "#/components/schemas/Error"
|
|
example:
|
|
code: "unknown_error"
|
|
message: "The request conflicted with another request. You may retry the request with the provided Idempotency-Key."
|
|
type: "QueryRunnerAlreadyReleasedError"
|
|
invalid_request_error:
|
|
description: Invalid Request Error
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: "#/components/schemas/Error"
|
|
example:
|
|
code: "invalid_request_error"
|
|
message: "Discount with code TEST already exists."
|
|
type: "duplicate_error"
|
|
not_found_error:
|
|
description: Not Found Error
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: "#/components/schemas/Error"
|
|
example:
|
|
message: "Entity with id 1 was not found"
|
|
type: "not_found"
|
|
400_error:
|
|
description: Client Error or Multiple Errors
|
|
content:
|
|
application/json:
|
|
schema:
|
|
oneOf:
|
|
- $ref: "#/components/schemas/Error"
|
|
- $ref: "#/components/schemas/MultipleErrors"
|
|
examples:
|
|
not_allowed:
|
|
$ref: "#/components/examples/not_allowed_error"
|
|
invalid_data:
|
|
$ref: "#/components/examples/invalid_data_error"
|
|
MultipleErrors:
|
|
$ref: "#/components/examples/multiple_errors"
|
|
500_error:
|
|
description: Server Error
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: "#/components/schemas/Error"
|
|
examples:
|
|
database:
|
|
$ref: "#/components/examples/database_error"
|
|
unexpected_state:
|
|
$ref: "#/components/examples/unexpected_state_error"
|
|
invalid_argument:
|
|
$ref: "#/components/examples/invalid_argument_error"
|
|
default_error:
|
|
$ref: "#/components/examples/default_error"
|
|
unauthorized:
|
|
description: 'User is not authorized. Must log in first'
|
|
content:
|
|
text/plain:
|
|
schema:
|
|
type: string
|
|
default: Unauthorized
|
|
example: Unauthorized
|
|
incorrect_credentials:
|
|
description: 'User does not exist or incorrect credentials'
|
|
content:
|
|
text/plain:
|
|
schema:
|
|
type: string
|
|
default: Unauthorized
|
|
example: Unauthorized
|
|
examples:
|
|
not_allowed_error:
|
|
summary: Not Allowed Error
|
|
value:
|
|
message: "Discount must be set to dynamic"
|
|
type: "not_allowed"
|
|
invalid_data_error:
|
|
summary: Invalid Data Error
|
|
value:
|
|
message: "first_name must be a string"
|
|
type: "invalid_data"
|
|
multiple_errors:
|
|
summary: Multiple Errors
|
|
value:
|
|
message: "Provided request body contains errors. Please check the data and retry the request"
|
|
errors:
|
|
- message: "first_name must be a string"
|
|
type: "invalid_data"
|
|
- message: "Discount must be set to dynamic"
|
|
type: "not_allowed"
|
|
database_error:
|
|
summary: Database Error
|
|
value:
|
|
code: "api_error"
|
|
message: "An error occured while hashing password"
|
|
type: "database_error"
|
|
unexpected_state_error:
|
|
summary: Unexpected State Error
|
|
value:
|
|
message: "cart.total must be defined"
|
|
type: "unexpected_state"
|
|
invalid_argument_error:
|
|
summary: Invalid Argument Error
|
|
value:
|
|
message: "cart.total must be defined"
|
|
type: "unexpected_state"
|
|
default_error:
|
|
summary: Default Error
|
|
value:
|
|
code: "unknown_error"
|
|
message: "An unknown error occurred."
|
|
type: "unknown_error"
|
|
securitySchemes:
|
|
api_token:
|
|
type: http
|
|
x-displayName: API Token
|
|
description: |
|
|
Use a user's API Token to send authenticated requests.
|
|
|
|
### How to Add API Token to a User
|
|
|
|
At the moment, there's no direct way of adding an API Token for a user. The only way it can be done is through directly editing the database.
|
|
|
|
If you're using a PostgreSQL database, you can run the following commands in your command line to add API token:
|
|
|
|
```bash
|
|
psql -d <DB_NAME> -U <DB_USER>
|
|
UPDATE public.user SET api_token='<API_TOKEN>' WHERE email='<USER_EMAIL>';
|
|
```
|
|
|
|
Where:
|
|
- `<DB_NAME>` is the name of the database schema you use for the Medusa server.
|
|
- `<DB_USER>` is the name of the user that has privileges over the database schema.
|
|
- `<API_TOKEN>` is the API token you want to associate with the user. You can use [this tool to generate a random token](https://randomkeygen.com/).
|
|
- `<USER_EMAIL>` is the email address of the admin user you want to have this API token.
|
|
|
|
### How to Use the API Token
|
|
|
|
The API token can be used for Bearer Authentication. It's passed in the `Authorization` header as the following:
|
|
|
|
```
|
|
Authorization: Bearer {api_token}
|
|
```
|
|
|
|
In this API reference, you'll find in the cURL request samples the use of `{api_token}`. This is where you must pass the API token.
|
|
|
|
If you're following along with the JS Client request samples, you must provide the `apiKey` option when creating the Medusa client:
|
|
|
|
```ts
|
|
const medusa = new Medusa({ baseUrl: MEDUSA_BACKEND_URL, maxRetries: 3, apiKey: '{api_token}' })
|
|
```
|
|
|
|
If you're using Medusa React, you can pass the `apiKey` prop to `MedusaProvider`:
|
|
|
|
```tsx
|
|
<MedusaProvider
|
|
apiKey='api_token}'
|
|
//...
|
|
>
|
|
```
|
|
scheme: bearer
|
|
cookie_auth:
|
|
type: apiKey
|
|
in: cookie
|
|
name: connect.sid
|
|
x-displayName: Cookie Session ID
|
|
description: |
|
|
Use a cookie session to send authenticated requests.
|
|
|
|
### How to Obtain the Cookie Session
|
|
|
|
If you're sending requests through a browser, using JS Client, or using tools like Postman, the cookie session should be automatically set when the admin user is logged in.
|
|
|
|
If you're sending requests using cURL, you must set the Session ID in the cookie manually.
|
|
|
|
To do that, send a request to [authenticate the user](#tag/Auth/operation/PostAuth) and pass the cURL option `-v`:
|
|
|
|
```bash
|
|
curl -v --location --request POST 'https://medusa-url.com/admin/auth' \
|
|
--header 'Content-Type: application/json' \
|
|
--data-raw '{
|
|
"email": "user@example.com",
|
|
"password": "supersecret"
|
|
}'
|
|
```
|
|
|
|
The headers will be logged in the terminal as well as the response. You should find in the headers a Cookie header similar to this:
|
|
|
|
```bash
|
|
Set-Cookie: connect.sid=s%3A2Bu8BkaP9JUfHu9rG59G16Ma0QZf6Gj1.WT549XqX37PN8n0OecqnMCq798eLjZC5IT7yiDCBHPM;
|
|
```
|
|
|
|
Copy the value after `connect.sid` (without the `;` at the end) and pass it as a cookie in subsequent requests as the following:
|
|
|
|
```bash
|
|
curl --location --request GET 'https://medusa-url.com/admin/products' \
|
|
--header 'Cookie: connect.sid={sid}'
|
|
```
|
|
|
|
Where `{sid}` is the value of `connect.sid` that you copied. |