REST API

The Marketplace EQP REST API is completely separate from APIs provided with Magento 2.

There is no corresponding GraphQL or SOAP API.

The Marketplace EQP API gives you access to your Marketplace Developer Portal resources. These resources are managed by a set of REST API endpoints.

Overview of resources

Resource	Purpose
authentication	Obtain a session token
users	Manage your profile
files	Manage your profile avatar, ZIP files, image files, PDF documents
packages	Initiate and manage your submissions
test results	Receive information about automated and manual reviews
reports	Get information about your sales, as well as your Commerce Marketplace web pages
API callbacks	Request notification as specific workflow activities happen

General concepts

Base URLs

The API endpoints only accept encrypted communications using HTTPS at the following base URLs:

Environment	Base Url
sandbox	`https://commercedeveloper-sandbox-api.adobe.com`
production	`https://commercedeveloper-api.adobe.com`

REST HTTP verbs

The Marketplace EQP API is based on REST concepts and uses standard HTTP verbs:

HTTP Verb	Usage
GET	Retrieves a resource, or retrieves a collection of that resource
POST	Creates a resource
PUT	Updates the entire resource, or updates part of a resource (when acting like a PATCH)
DELETE	Removes a resource

API versioning

All endpoints start with /rest/v1, which supports versioning. The initial release is version 1 (v1).

JSON

Except when creating the file resource, all requests are formatted using JSON.
All responses are formatted using JSON.

UTC timestamps

All timestamps are in UTC (universal time coordinated).

Batch processing

Some endpoints can handle a batch request, such as the following:

POST /rest/v1/products/packages
PUT /rest/v1/products/packages   // used when updating multiple packages in one request
Copied to your clipboard
POST /rest/v1/products/packages
PUT /rest/v1/products/packages   // used when updating multiple packages in one request

Batch response

Endpoints that are batch requests return responses as follows. See specific examples in the section about handling errors.

Complete processing failure

If an error occurs with the entire payload (for example, the user is not authorized to make the request) the appropriate HTTP 4xx code will be returned.
No additional processing of the batch request was attempted, and therefore there will not be any itemized response.

Typical processing

If the batch request can be processed, the overall HTTP code of the batch response will always be HTTP 200 OK regardless of the pass/fail status of the items in the batch.
The batch response contains information about every item in the batch request.
The order of these items matches the order in the batch request.
Every item in the batch response includes two additional fields that indicate the pass/fail status of the operation on that item:
- code - Contains an integer status code related to the operation. Failure of an operation is indicated by a non-200 value
- message - Contains a human readable message that describes the reason for the code.
Items in a batch that can be completed successfully will be completed, regardless of the pass/fail status of other items in the batch.