Loading...
OpenAPI Directory | Cenit Admin

Explore all our endpoints with your own set of of access tokens. All changes affect your production Jumpseller store.

Delivery Service API

Some calls require HTTPS and an Authorization Key which will be provided by Just Eat.

The key needs to be provided in the header as follows: Authorization: JE-API-KEY {Your-Key-Here}

This is the koomalooma Partner API. koomalooma is the first Loyalty BPaaS (Business Process as a Service) for mobile and web companies. With koomalooma merchants issue points for actions their customers / users make on your mobile or web store, for example a purchase or a referral. koomalooma takes care of all the rest, from signing up users, keeping track of points and delivering rewards in over 80 countries. koomalooma offers an easy to integrate API and web backend to configure loyalty campaigns and track performance. You can find more at http://support.koomalooma.com

Magento Commerce is the leading provider of open omnichannel innovation.

Provides a RESTful API for interacting with virtual cash registers and creating receipts that are conform with the Registrierkassensicherheitsverordnung (RKSV). You may find our [automatically generated clients](./clients) for various programming languages and environments helpful...

## Who is this for? This documentation is for developers creating their own integration with [Feedback's](https://www.pendo.io/product/feedback/) API. If you are doing a standard integration, there's a really easy [Javascript integration](https://help.receptive.io/hc/en-us/articles/209221969-How-to-integrate-Receptive-with-your-app) that you should know about before you go to the effort of building your own integration. ## Authentication API calls generally need to be authenticated. Generate an API Key at https://feedback.pendo.io/app/#/vendor/settings?section=integrate. This key should then be added to every request URL as a query parameter named 'auth-token' ## Endpoint API endpoint is https://api.feedback.eu.pendo.io / https://api.feedback.us.pendo.io depending where your datacenter is located. ## Notes API endpoints are being added to this documentation as needed by customers. If you don't see an endpoint you need please contact support and if it exists we'll publish the docs here. The 'try it out' feature on this documentation page will probably be blocked by your browser because the Access-Control-Allow-Origin header has its value set by the Feedback server depending on your hostname. ## Generating client code This documentation is automatically generated from an OpenAPI spec available [here](http://apidoc.receptive.io/receptive.swagger.json). You can use Swagger to auto-generate API client code in many languages using the [Swagger Editor](http://editor.swagger.io/#/)

Hereafter is the documentation of the private API of [Pims: Pointages Intelligents pour le Monde du Spectacle](https://pims.io). This API is designed for 3rd-party softwares, editors and partners. Its main purpose is to give access the core data of a Pims customer (i.e. events, ticket counts and promotions). ## Authentication The API uses [basic access authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), meaning you will need a username and password to get authorized. As each customer in Pims has its own domain (e.g. caramba.pims.io, gdp.pims.io...), each credentials will be valid for one domain/customer only. If you need dedicated credentials for one domain, please contact us. (In any case, we will need an explicit agreement from the customer before we create these credentials.)

To make your life easy, you can try all endpoints with the public credentials below, pointing to our [demo domain](https://demo.pims.io):
  • Base path: `https://demo.pims.io/api`
  • Username: `demo`
  • Password: `q83792db2GCvgYVdKpU3yG3R`
## Response format The API returns JSON and matches the [HAL specification](http://stateless.co/hal_specification.html). The `Content-Type` of each response will be `application/hal+json`, unless an error occurs. Please note that this documentation describes all responses “as if” they were plain JSON. The specificities of HAL are ignored on purpose, in order to remain compact and avoid repetition.
So when you read in the doc:
{
	"id": 123,
	"property1": "Lorem ipsum",
	"object": {
		"id": 456,
		"property2": 7.89
	}
}
... you'll get in the Real World®:
{
	"id": 123,
	"property2": "Lorem ipsum",
	"_embedded": {
		"object": {
			"id": 456,
			"property2": 7.89,
			"_links": {
				"self": {
					"href": "https://api.mydomain.com/other-item/456"
				}
			}
		}
	}
	"_links": {
		"self": {
			"href": "https://api.mydomain.com/item/123"
		}
	}
}
### Errors Errors return JSON too and tries to match the [Problem Details for HTTP APIs specification](https://tools.ietf.org/html/rfc7807). If it does not match this spec, that's either a bug or a compatibility issue. Please contact us to solve the problem. The `Content-Type` of errors will be `application/problem+json`. The content will match the following JSON: ```json { "type": "https://tools.ietf.org/html/rfc2616#section-10", "title": "Not Found", "status": 404, "detail": "Entity not found" } ``` ## Versioning The API is fully versionned, using an URL-versioning scheme: `https://demo.pims.io/api/v1/events`, `https://demo.pims.io/api/v2/events`,... The version part of the URL is optional, and will be completed with the last stable version if omitted. ## Pagination All responses corresponding to a collection of resources (e.g. `/venues` or `/series/:id/events`) are paginated. When so, you will only get the first 25 resources you asked for. If you need to get more resources in one call, you can use the `page_size` query parameter. E.g. `/venues?page_size=50` to get the 50 first venues. Also note that with HAL, the navigation in paginated responses is a piece of cake, as you can see below: ```json { "_links": { "self": { "href": "https://demo.pims.io/api/v1/events?page=1" }, "first": { "href": "https://demo.pims.io/api/v1/events" }, "last": { "href": "https://demo.pims.io/api/v1/events?page=14" }, "next": { "href": "https://demo.pims.io/api/v1/events?page=2" } }, "_embedded": { ... // data content goes here }, "page_count": 14, "page_size": 25, "total_items": 331, "page": 1 } ``` ## Filtering and sorting Every textual filter (e.g. `/events?label=U2`) and/or sort (e.g. `/events?sort=label`) performed with the API uses UTF8_UNICODE_CI collation, meaning it is: - Case insensitive: “Chloé” will be considered the same as “CHLOÉ”; - Diacritic insensitive: “Chloé” will be considered the same as “Chloe”. When performing a sort, it will always be *ascending* by default. To make it *descending*, just use a minus sign (`-`) in front of the parameter value (e.g. `/events?sort=-label`). ## I18n In responses, some labels can be translated (e.g. promotion types, event input types, etc.). These translatable labels are clearly indicated in the documentation below. By default, they will be displayed in English, but you can change this behaviour via the `Accept-Language` header. E.g., use `fr` as a value for French. ## PHP SDK We provide a simple yet convenient SDK for the PHP language, see [the Github page of the project](https://github.com/pimssas/pims-api-client-php). ## And now? Generaly, you will start by [fetching one or more events](#tag/Events). An event can be anything that occurs in one venue at one given date and time: a concert, a play, a match, a conference, etc. Additionnally, you can explore the [series](#tag/Series): a series is just a group of events (e.g. a tour or a festival). Once you retrieved the events you were interested in, you can look for the sales (ticket counts): - Get a quick overview with [`/events/:id/ticket-counts`](#operation/fetchAllTicketCounts) - Or get a full insight by calling these endpoints: 1. [`/events/:id/categories`](#operation/fetchAllEventsCategories) 2. [`/events/:id/channels`](#operation/fetchAllEventsChannels) 3. [`/events/:id/ticket-counts/detailed`](#operation/fetchAllDetailedTicketCounts) Eventually, you may also want to fetch the [promotions](#tag/Promotions). A promotion can be anything meant to leverage the sales: ads, marketing campaigns, buzz or news around the event, etc. A promotion can be linked to any combination of events and/or series.

This document describes the Qualpay Payment Gateway API.

reverb

# Integrating with ShipStation ShipStation strives to streamline shipping for online sellers, no matter where they sell their products online. We are continuously adding new marketplaces, shopping carts, and integration tools, because we know the e-commerce space is growing. As a result, we’ve worked hard to provide developer resources to build custom integrations with ShipStation. If you’re interested in becoming a partner of ours, drop us a line by [filling out this form](http://www.shipstation.com/partners/shipstation-api-custom-store/) and we’ll get in touch. There are two methods to integrate with ShipStation: * Custom Store Integration * ShipStation API ## Custom Store Integration Looking for a more 1-to-1 relationship between ShipStation and your chosen selling platform? The Custom Store Integration is the ticket. Our custom store integration is just like any of our other selling channel integration, and could be eligible (based on internal review) as a branded option within the ShipStation admin. It also allows the user to sync orders within ShipStation in a single click, in addition to ShipStation automatically sending shipment status and tracking information updates back to your cart or marketplace once a label is created. It’s the best way to sync up orders with ShipStation and have the most seamless experience. The Custom Store allows you to perform two major functions: * Provide order information to ShipStation, including recipient address, products, customers, etc. * Receive tracking information when an order is shipped, including shipping method, shipping status, tracking number, and more To integrate with the Custom Store, you must expose a web page that renders XML that adheres to the specification defined in the Custom Store Integration Guide. We refer to this page as your “XML Endpoint”. If you can provide us an XML Endpoint, we can *pull* data from your endpoint just like we do with other marketplaces like eBay and Amazon. **To find out more about our Custom Store Integration, click here: [Custom Store Integration Guide](https://help.shipstation.com/hc/en-us/articles/205928478)** ## ShipStation API Our API is available for any plan, and allows for read access to almost all data in your account, and write access to create specific objects, like Orders, Customers, and Products. The API is a great way to get data directly to and from ShipStation, like creating products, customers, and querying order & shipping data. Please note that an API integration will not allow you to use your own MarketplaceID that could eventually be branded with your company's logo (see the Custom Store Integration above for that functionality). **This API allows developers to build applications that interface with the ShipStation platform. The API can be used to automate many tasks including:** + Managing Orders + Managing Shipments + Creating Shipping Labels + Retrieving Shipping Rates + and more!!! **To learn more about our API, please review our API documentation below.** ## Which one should I pick? The method that's right for your integration very much depends on the type of integration you're planning on implementing. A Custom Store allows ShipStation to *pull* order information from your platform the very same way we *pull* data from marketplaces such as eBay, Amazon, and Shopify. Once an order has been shipped in ShipStation, ShipStation automatically *pushes* tracking information back to your custom store. Though the functionality afforded by this approach is limited to these 2 main functions, much of the *heavy lifting* is performed by ShipStation. Importing orders and sending tracking information is performed automatically by ShipStation, as long as your XML endpoint is available to receive our data. An API integration, on the other hand, exposes much more functionality, but requires that the developer do much of the heavy lifting. Orders must be *pushed* to ShipStation by using our "/orders/CreateOrder" endpoint. The API allows developers to perform functions such as tagging an order, shipping an order, creating a shipping label (without an order), retrieving shipping rates, adding funds to a carrier account, creating a warehouse, listing products, and much more. The functionality the API affords are typical actions that a user would perform if using the web app. ### Considerations * **Will your integration be the main order management tool for the online seller?** If so, the API's broader range of functionality may be the best option. * **Would you like your store integration to be a branded marketplace within the ShipStation admin?** When you integrate using the Custom Store Integration, you could be eligible to have your company branded within the ShipStation admin. A branded store could have the plugin's logo in the app, as well as an easier store setup, order sync, and reporting. Please note, ShipStation makes the final decision, based on integration and partner requirements, on which custom stores are branded within our application. # ShipStation API Requirements ## End Point Endpoints are located at the following domain https://ssapi.shipstation.com/ and will need to have a specific reference added to return data. PLEASE NOTE: You cannot access this URL directly and must reference one of the specific endpoints below. ## Authentication The ShipStation API uses [Basic HTTP authentication](http://en.wikipedia.org/wiki/Basic_access_authentication). Use your ShipStation ``API Key`` as the username and ``API Secret`` as the password. You can find your ``API Key`` as the username and ``API Secret`` under Settings at https://ss.shipstation.com/#/settings/api . The Authorization header is constructed as follows: + Username (``API KEY``) and password (``API Secret``) are combined into a string "username:password" + The resulting string is then encoded using the RFC2045-MIME variant of Base64, except not limited to 76 char/line + The authorization method and a space i.e. "Basic " is then put before the encoded string. For example, if the ``API KEY`` given is 'ShipStation' and the ``API Secret`` is 'Rocks' then the header is formed as follows: + Authorization: Basic U2hpcFN0YXRpb246Um9ja3M= ## API Rate Limits In an effort to ensure consistent application performance and increased scalability, we have implemented rate limiting on the ShipStation API. Your integration will need to be able to handle HTTP rate limiting status messages as defined below: **Response Headers** All responses will include headers with status information about rate limiting. 1. X-Rate-Limit-Limit: the maximum number of requests per minute to the endpoint 2. X-Rate-Limit-Remaining: the available requests remaining in the current window 3. X-Rate-Limit-Reset: the number of seconds remaining until the next window begins **Hitting the Limit** If your application hits the rate limit, an HTTP 429 will be returned with this body: ``` { "message": "Too Many Requests" } ``` And these headers, assuming it is 40 seconds into the current window: ``` { "X-Rate-Limit-Limit": 40, "X-Rate-Limit-Remaining": 0, "X-Rate-Limit-Reset": 20 } ``` When the limit is reached, your application should stop making requests until X-Rate-Limit-Reset seconds have elapsed. The current Rate limit for each set of the API Key and Secret is 40 requests per minute. If you have any issues with the API, please email us at ## Server Responses Status Code | Description ------------|------------- ``200`` | OK - The request was successful (some API calls may return 201 instead). ``201`` | Created - The request was successful and a resource was created. ``204`` | No Content - The request was successful but there is no representation to return (that is, the response is empty). ``400`` | Bad Request - The request could not be understood or was missing required parameters. ``401`` | Unauthorized - Authentication failed or user does not have permissions for the requested operation. ``403`` | Forbidden - Access denied. ``404`` | Not Found - Resource was not found. ``405`` | Method Not Allowed - Requested method is not supported for the specified resource. ``429`` | Too Many Requests - Exceeded ShipStation API limits. When the limit is reached, your application should stop making requests until X-Rate-Limit-Reset seconds have elapsed. ``500`` | Internal Server Error - ShipStation has encountered an error. ## DateTime Format and Time Zone ShipStation uses the ISO 8601 combined format for dateTime stamps being submitted to and returned from the API. Please be sure to submit all dateTime values as follows: yyyy-mm-dd hh:mm:ss (24 hour notation). Example - ``2016-11-29 23:59:59`` The time zone represented in all API responses is PST/PDT. Similarly, ShipStation asks that you make all time zone convertions and submit any dateTime requests in PST/PDT.

This is an API designed for merchants who are using SpectroCoin services and wishes to integrate them locally.

Please make sure you use the correct version of the APIs for your use case. To find out the appropriate version, go to the API Docs drop down on the menu.

Please make sure you use the correct version of the APIs for your use case. To find out the appropriate version, go to the API Docs drop down on the menu.

Please make sure you use the correct version of the APIs for your use case. To find out the appropriate version, go to the API Docs drop down on the menu.

42 api specs