In this section you will learn how to interact with our web service and connect with our orering platform. As you go through the documentation of the different endpoints, you may want to test how our API works and what can you get from it.
The IFS web service is built on tried and true data transfer standards. Our API is built on the Representational State Transfer (REST) protocol. It is worth gleaning A basic understanding of REST if you do not already as it will make incorporating our web services much easier.
As with most REST services our endpoints often use the same parameters with your different GETs, POSTs, PUTs and DELETEs. The specific characteristics are detailed on our API Reference Page
Information accesible within IFS is dependent on one or more business "roles" assigned to your user account. Your role name must be included in IFS urls when using API endpoint specific to your role (more on API URL conventions).
API URL Convention
API calls use a strict and predictable convention within their URLs. Documented below are the individual pieces to a web service URL.
The base url for all api calls begins with "api" after the host URL.
API calls require that a role assigned by us be used in the webservice URL. The role provided is validated against your IFS account and is also used to get or post information to your organization.
Some api calls such getting a specific order's detail require an id to be supplied in the URL. ID typically represents an index identifier needed to call a specific data set. For instance when getting an order's detail, id represents the order's order number.
The id url segment is skipped on calls that do not require it.
Here is an example of an API call to retrieve details for an order with the order number "10" where the organization (role) is named "Sprockets".
Many api calls require extra parameters to be sent in the request's query string.
Here is an example of an API call to retrieve a summary of new orders if your organization (role) is named "Sprockets".
The IFS webservice uses basic authentication to validate requests. Basic authentication requires a user name and password passed in the request header as a Base64 encoded string. Applying the encoding depends on your platform. An example of how to do this using cURL is provided below.
Sending a request
All requests must be sent over http (web) protocol. The method of transport is largely up to your toolset. Below is an example provided in PHP.
Submitted orders are imported in 30 minute intervals thus will not immediately display on your orders list. Note that all SKU’s must be setup in our system prior to being submitted with an order. If an order is submitted with a SKU that isn’t on your list of SKU’s then it won’t be imported into our system.
Error Codes & Reponses
An API testing tool perfect for testing web service calls provided within this document.
Further reading on the REST protocol.
A great online tool for testing and automating your API calls.
Webhooks event driven HTTP callbacks that send data to a URL endpoint you define. Given the correct permissions, you can setup your webhooks by logging, navigating to the dashboard, clicking on your profile and then clicking the webhooks link.
Webhook Response Format
You can decide whether the data sent to your endpoint is formatted as JSON or XML.