To use the Infoplus API, first you must have access to an Infoplus account.
If you already have an account, you should know its domain name, which
will look like ${your-company-identifier}.infopluswms.com.
If you do not have an Infoplus account, you may use our demo account,
or you can request your own account.
The only other thing you need to start working with the Infoplus API is an API Key. You can create an API Key from within your Infoplus account, by browsing to the User table, then clicking the pill in the API Key column, and selecting Create an API Key. Visit the Knowledge Base for more information.
All endpoints available in the Infoplus API can be accessed directly from this site. This is meant as a way to explore the API, and can be a useful tool for getting started.
The Infoplus API can be directly accessed via standard HTTP requests. Production applications may be built this way, however, we recommend using our Client Libraries - see below.
URLs for the Infoplus API all require https://, followed by of 3 variable parts: https://${DOMAIN}${BASEPATH}${RESOURCE}
${DOMAIN} - This is the domain specific to your Infoplus account. e.g., carlscandy.infopluswms.com${BASEPATH} - This will always be the path: /infoplus-wms/api${RESOURCE} - Based on the specific version and endpoint being called. e.g., /v1.0/warehouse/search
These parts can be composed into a URL, and then used with an API-Key header,
to make a request to the Infoplus API. For example, to search your account for Warehouse records:
curl -s -H API-Key:${API_KEY} https://${DOMAIN}/infoplus-wms/api/v1.0/warehouse/search
Some API endpoints take query-string parameters (specifically, the search endpoints). The values
for these parameters must be URI encoded. For example, the following request searches the Item
table for at most 3 records with the status of Active.
curl -s -H API-Key:${API_KEY} "https://${DOMAIN}/infoplus-wms/api/v1.0/item/search?filter=status%20eq%20Active&limit=3"
The Infoplus API uses the HTTP method POST to perform Inserts, PUT
to perform Updates, and DELETE to perform Deletes. For POST and
PUT requests, the header Content-Type:application/json must be given.
For example, to Insert a new Order Source:
curl -s -H API-Key:${API_KEY} -H Content-Type:application/json -X POST -d '{"lobId":10007,"name":"My Order Source"}' "https://${DOMAIN}/infoplus-wms/api/v1.0/orderSource"
The recommended technique for using the Infoplus API is to download one of our Client Libraries from the Infoplus github page.
These client libraries expose all endpoints and models of the API, and provide language standard error handling.
Implementation details vary per language, but in general, usage of the Infoplus API Client Libraries requires setting of the Base Path or Domain, along with setting the API Key, in a Configuration object, which is used to construct an ApiClient object, which is finally used to construct specific resource Api objects. For example, in PHP:
$configuration = new Infoplus\Configuration();
$configuration->setApiKey("API-Key", $apiKey);
$configuration->setHost("https://${domain}/infoplus-wms/api");
$apiClient = new Infoplus\ApiClient($configuration);
$orderApi = new Infoplus\Api\OrderApi($apiClient);
See specific per-language instructions on the corresponding project pages on github.com/infopluscommerce.
The API-Key HTTP Header is the only way to be authenticated to use the Infoplus API.
You may obtainan API Key from the Users table within Infoplus. See the Infoplus
Knowledge Base for more information on managing Users and API Keys in Infoplus.
Any request to the Infoplus API which does not include the API-Key Header, or which
contains an invalid value for the API Key will result in a HTTP 401 response.
The GET endpoints of the Infoplus API which return lists of records fall into two categories:
Those which return full, stand-alone records, which support ad hoc queries, specified via the filter
parameter, and others which only return possible-values to be used as part of other records, which support
the more limited searchText parameter.
For resources which support full ad hoc queries, the query string parameter filter is used to define
the query. The query may consist of one or more fields from the
record type being queried, followed by an operator, then zero or more values (depending on the operator).
Multiple fields are separated by the keyword and.
The following operators each require a single value to be given after the operator:
eq Equalsne Not Equalslike Like (only for Strings). Use % for wildcards.not like Not Like (only for Strings). Use % for wildcards.gt Greater than (only for Numbers and Dates)gte Greater than or Equals (only for Numbers and Dates)lt Less than (only for Numbers and Dates)lte Less than or Equals (only for Numbers and Dates)The following operators must not be given any value after the operator:
is blank Value is null or empty stringis not blank Value is not null nor empty stringThe following multi-valued operators are supported. They must be given a list of values, enclosed in parentheses, separated by commas:
between Value is between the first two values specified in the listnot between Value is not between the first two values specified in the listin Value is in the given listnot in Value is not in the given listSome example queries (shown without URI encoding) against the Order endpoint are:
status eq "On Order" Find all Orders in the status On Orderstatus eq "Processed" and numberOfLineItems gt 5 Find all Orders in the status Processed with more than 5 Line Items.customerOrderNo like "10%" and orderSourceId ne 42 Find all Orders with a customerOrderNumber that starts with 10, which are not from orderSource 42
Specifying an unrecognized field name, an invalid operator, or any other error in the format of the filter parameter
will result in a 400 HTTP error.
Note, starting with version 2.0, you can search for custom fields, as explained on our Knowledge Base.
For resources which support searching by a single text string, the query string parameter searchText
is used to perform a hybrid of a "like" and "starts-with" text search against the text values represented by the resource.
That is to say, the searchText can have % characters in it, to act as as wildcards, and an implicit wildcard
is added to the end of the searchText as well.
Some example searches against the User endpoint are:
Da Would find users Dan Johnson and David Smith.%Smith Would find users John Smith, David Smith, and Larry Smithson.
All search endpoints return paginated lists of records. By default, 20 records are returned. This can be overridden by
specifing the limit query string parameter. The largest allowed value for limit is 250. Specifying a larger value will return a 400 HTTP error.
By default, the first page of results is returned from search calls (i.e., no records are skipped from the start of the result set).
This can be overridden by specifying the page query string parameter. This parameter works in conjunction with the
limit parameter (defaulting to 20 if not specified),
to determine how many rows at the beginning of the result set are skipped, to implement paging of results.
The order in which records are returned from search endpoints can be controlled by using the sort query string parameter.
The value for this parameter must be a field name from the record type being queried. By default, results are ordered Ascending, but
if the field name is preceded by a ! character, then the results are ordered Descending.
Specifying an unrecognized field name, or any other error in the format of the sort parameter
will result in a 400 HTTP error.
All errors from the Infoplus API will be returned as HTTP errors in the 4xx range for client-side errors, or
5xx for server-side errors.
In the event of an error response code, the body of the response will include a JSON object consisting of a single key,
errors, whose value is a list of the one or more errors encountered while processing the request.
For language-specific error handling details, see the documentation that accompanies each individual Client Library on the Infoplus github page.
Infoplus is committed to never breaking the contract of a published version of the API. New minor versions of the api (e.g., 1.0 to 1.1) will only add new resources, endpoints, and/or fields - not change or remove anything. This implies that users of Infoplus API Client libraries should generally be able to upgrade the minor version of the API that they are using without having to re-write any existing code.
New major versions of the API (e.g., 1.1 to 2.0) may introduce non-backward compatible changes to existing resources or endpoints.
To aid both developers who are integrating with the Infoplus API, as well as end-users of Infoplus, all API requests made to Infoplus are recorded in the API Log table within Infoplus.
This table records the request Path, Body, Response code, and Error messages. It can be accessed within the Activity app in Infoplus.