It all starts here!
QA environment : Only for Monext usage
Try our sandbox : https://api-docs.retail.monext.com/
Introduction
The Monext Retail API is RESTful, meaning that it uses HTTP verbs (POST, PUT, GET...) to perform functions on resources.
Specifically, POST is used to create a resource, PUT to update a resource, and GET to retrieve a resource or a collection of resources.
For example, to create a new wallet resource you would send a POST request to Wallets.
POST and PUT requests usually require data to be passed in the message body to define the attributes of the object being created or updated.
Open API Specification
The Open API specification file : Open API Specification file
Endpoints
Production : https://api.retail.monext.com
Sandbox (homologation) : https://api-sandbox.retail.monext.com
DEV1 : https://develop-dev1-rest-api.ext.dev.payline.com
DEV2 (Docker) : https://develop-dev2-rest-api.ext.dev.payline.com
DEV2 : https://admin.dev.payline.com/new-api
Versioning
The API version is indicated in each endpoint resource path. For example, https://api-sandbox.retail.monext.com/v1/checkout indicates the API is at version 1.
Monext increments the version number when it releases a new version containing backwards-incompatible changes.
Some minor changes, mostly for improvements, could happen without version changes.
Security
The Monext Retail API processes sensitive data. That's why we pay special attention to security.
- Monext data centers deploy the latest in hardware and software security best practices.
- Communication with all Monext services requires TLS 1.1 or TLS1.2.
- All communication is made by using standard features of HTTPs.
- Monext maintains PCI-DSS compliance certifications.
Responses
Monext Retail API calls return HTTP status codes. Some API calls also return JSON response bodies that include information about the resource.
When you create any Monext resource, the system associates an internal unique identifier for referencing that resource.
HTTP Status Code
Each API call returns a success or error HTTP status codes following the RFC7231.
Success
The following status codes of HTTP are used:
2xx - the request was successfully accepted and was or will be processed.
Error
The following status codes of HTTP are used:
4xx - the request was rejected due to a problem with the information sent by the client.
5xx - something unexpected occurred while fulfilling the request; the request may or may not have been processed, depending on the error.
Whenever a client receives a 5xx response, it should not assume anything about the processing state of such request.
Authentication
| Security Scheme Type | HTTP | Server |
|---|---|---|
| HTTP Authorization Scheme | basic |
Query
For most REST GET calls, you can specify one or more optional query parameters on the request URI to filter, limit the size of, and sort the data in an API response. For filter parameters, see the individual GET calls.
Sorting and Pagination
Rather than return everything from a large result set, we are using some URL parameters that will influence the page size and starting page number.
Query parameter details
| Parameter | Type | Description |
|---|---|---|
| size | integer | The number of items to list in the response. |
| page | integer | The page index. |
| sort | string | Sorts resources in the response by a specified value and sort direction. |
Response field details
| Parameter | Type | Description |
| count | integer | The number of items to list in the response. |
| startIndex | integer | The sort order index of the first resource in the returned array. |
| endIndex | integer | The sort order index of the last resource in the returned array. |
| recordTotal | integer | count of records |