This PHP package is automatically generated by the Swagger Codegen project:
- API version: v2
- Package version:
- Build date: 2016-07-26T12:25:29.354Z
- Build package: class io.swagger.codegen.languages.PhpClientCodegen
PHP 5.4.0 and later
To install the bindings via Composer, add the following to composer.json
:
{
"repositories": [
{
"type": "git",
"url": "https://github.com//.git"
}
],
"require": {
"/": "*@dev"
}
}
Then run composer install
Download the files and include autoload.php
:
require_once('/path/to/SwaggerClient-php/autoload.php');
To run the unit tests:
composer install
./vendor/bin/phpunit lib/Tests
Please follow the installation procedure and then run the following:
<?php
require_once(__DIR__ . '/vendor/autoload.php');
$api_instance = new Swagger\Client\Api\BackOrderApi();
$back_order = new \Swagger\Client\Model\BackOrderViewModel(); // \Swagger\Client\Model\BackOrderViewModel |
try {
$result = $api_instance->backOrderCreate($back_order);
print_r($result);
} catch (Exception $e) {
echo 'Exception when calling BackOrderApi->backOrderCreate: ', $e->getMessage(), PHP_EOL;
}
?>
All URIs are relative to https://demo.channelengine.net/api
Class | Method | HTTP request | Description |
---|---|---|---|
BackOrderApi | backOrderCreate | POST /v2/backorders | Mark (part of) an order as in backorder. |
BackOrderApi | backOrderGet | GET /v2/backorders/{merchantReference} | Retrieve a backorder by its reference. A back order references the order which is temporarly out of stock. |
BackOrderApi | backOrderIndex | GET /v2/backorders | Gets all backorders created since the supplied date. |
CancellationApi | cancellationCreate | POST /v2/cancellations | Mark (part of) an order as cancelled. |
CancellationApi | cancellationGet | GET /v2/cancellations/{merchantReference} | Get a cancellation by its merchant reference. |
CancellationApi | cancellationIndex | GET /v2/cancellations | Gets all cancellations created since the supplied date. |
OrderApi | orderCreate | POST /v2/orders | Create a new order in ChannelEngine. |
OrderApi | orderCreate_0 | POST /v2/orders/acknowledge | Acknowledge an order. By acknowledging the order the merchant can confirm that the order has been imported. When acknowledging an order the merchant has to supply references that uniquely identify the order and the order lines. These references will be used in the other API calls. |
OrderApi | orderGet | GET /v2/orders/{merchantReference} | |
OrderApi | orderGetNew | GET /v2/orders/new | Fetch newly placed orders (order with status NEW). |
ProductApi | productAcknowledgeDataChanges | POST /v2/products/data | This endpoint should be called after a call to GET 'v2/products/data'. After a call to this endpoint ChannelEngine 'knows' which products are known to the channel (and the last time they have been updated) and is therefore able to only return the products that really have changed since the last call to POST 'v2/products/data'. The supplied ChannelReference will be saved in our database and is supposed to be unique, the 'Updated' and 'Removed' fields consist of ChannelReferences which are sent in a previous call within the field 'Created'. |
ProductApi | productAcknowledgeOfferChanges | POST /v2/products/offers | After a call to GET 'v2/products/offers' this endpoint should be called with the ChannelReference of the products that are successfully updated. Please see 'v2/products/data' and 'v2/products/data' for documentation. |
ProductApi | productCreate | POST /v2/products | Create a product. The parent serves as the 'base' product of the children. For example, the children could be different sizes or colors of the parent product. For channels where every size and color are different products this does not make any difference (the children will just be sent separately, while ignoring the parent). But there are channels where the parent and the children need to be sent together, for example when there is one product with a list of sizes. In this case all the product information is retrieved from the parent product while the size list is generated from the children. Note that the parent itself is a 'blueprint' of the child products and we do our best to make sure it does not end up on the marketplaces itself. Only the children can be purchased. It's not possible to nest parent and children more than one level (A parent can have many children, but any child cannot itself also have children). The supplied MerchantProductReference needs to be unique. |
ProductApi | productDelete | DELETE /v2/products/{merchantReference} | Deactivate a product based on the merchant reference. Note that we do not really delete a product, as the product might still be referenced by orders etc. |
ProductApi | productGet | GET /v2/products/{merchantReference} | Retrieve a product based on the merchant reference. |
ProductApi | productGetDataChanges | GET /v2/products/data | Get all products which have changes since the post http call to POST 'v2/products/data'. The response contains the products which should be created, updated or removed from the channel. After the products have been received and processed successfully 'v2/products/data' should be called with the merchant references of the products which have been processed (see POST 'v2/products/data'). ChannelEnginewill save this information to make sure that the next call to GET 'v2/products/data' only returns the products that really have changes (and therefore should be created, updated or deleted). A channel willing to integrate with channelengine should therefore only do the following things: 1. Periodically poll 'v2/products/data' for changes. 2. If any products are returned, save, update or remove these products. 3. Send the merchant references of the products that have succesfully been processed in step 2 to POST 'v2/products/data'. These three simple steps will make sure that the products on the channel will be synchronized with the products on ChannelEngine. ChannelEngine will use the API key to determine the customer whose products should be returned. |
ProductApi | productGetOfferChanges | GET /v2/products/offers | GET 'v2/products/offers' and POST 'v2/products/offers' closely resemble GET 'v2/products/data' and POST 'v2/products/data'. See the 'v2/products/data' endpoints for documentation. The difference between both endpoints is that 'v2/products/offers' only returns Price and Stock updates and can (and should) therefore be called more often to keep this information (which might change frequently) up to date. |
ReturnApi | returnCreate | POST /v2/returns | Mark (part of) an order as returned by the customer |
ReturnApi | returnGet | GET /v2/returns/{merchantReference} | Get a return by its merchant reference. |
ReturnApi | returnIndex | GET /v2/returns | Gets all returns created since the supplied date. |
ShipmentApi | shipmentCreate | POST /v2/shipments | Mark (part of) an order as shipped. |
ShipmentApi | shipmentGet | GET /v2/shipments/{merchantReference} | Get a shipment by its merchant reference. |
ShipmentApi | shipmentIndex | GET /v2/shipments | Gets all shipments created since the supplied date. |
- AcknowledgementLineViewModel
- Address
- BackOrderLineViewModel
- BackOrderViewModel
- CancellationLineViewModel
- CancellationViewModel
- CreateOrderLineViewModel
- CreateOrderViewModel
- Object
- OfferViewModel
- OrderAcknowledgementViewModel
- OrderLineViewModel
- OrderViewModel
- ProcessedChanges
- ProductChangesViewModel
- ProductRequestViewModel
- ProductResponseViewModel
- ProductViewModel
- References
- ReturnLineViewModel
- ReturnViewModel
- ShipmentLineViewModel
- ShipmentMethod
- ShipmentViewModel
- Type: API key
- API key parameter name: apikey
- Location: URL query string