Using the Whiplash API, you can do any task you would normally do via the app UI and more.

Customers who build into the Whiplash API typically have their internal development team or collaborate with a third-party development company to create a custom integration for their eCommerce shop.

In this article: 

• Getting started with the V2 API
• Sandbox testing process & best practices
• Related API documentation
• Other API versions

Getting started with the V2 API

It is strongly recommended that new API integrations be built out first in the Whiplash Sandbox (testing) environment before integrating into the Whiplash Production (live) environment.

Step 1: Build an integration in Whiplash Sandbox

The Sandbox environment is located at https://sandbox.getwhiplash.com/.

Whiplash offers one Sandbox account per customer. To request your account, please complete and submit the following form. A representative from Whiplash Tech Support will respond within 24 hours (Monday - Friday). 

For detailed instructions, see the Sandbox Testing process & best practices below.

Step 2: Move to Whiplash Production (live) after testing

The Production environment is located at https://app.getwhiplash.com/. 

When you are ready to deploy your integration to the Production environment, connect with your Whiplash Sales Representative for the next steps.

Sandbox testing process & best practices

The Whiplash team cannot advise on how best to architect your end of the integration. But, there are a few basic flows that most customers use and are a good place to start.

Authenticate your connection – you must have a Whiplash User

You must have a Whiplash user account and API Credentials to authenticate into the API. See Authentication for the V2 API for more information.

If you don’t have API credentials yet, you can request them using this form.

Item create/upload

Initially, you may want to upload your product catalog. We have a CSV template on the UI: Inventory > Import Items. Alternatively, you can create/update all your items via the API using the /items endpoint. See the Items developer documentation for more information.

Note:  In order to begin dropping orders against items, the items must first exist in Whiplash. So, item creation is the important first step so your orders will flow with no errors.

Create a Ship Notice to “receive” inventory to use in testing and to drop orders

Choose 10-15 items that you will test with and create a ship notice for 100-500 quantity of each. Your CSM or Tech point of contact can simulate a receipt and populate each item with quantity. See the ShipNotice developer documentation for more information.

Note: Choosing a manageable number of items to test with is preferred, rather than your entire product catalog. The receipt process is partially manual, so receiving a ship notice for 10-15 items will go a lot faster than receiving for hundreds or thousands of items.

Create an Order

Ensure you are passing the order with all required fields and a valid address. Add available items from above to the order. Drop links to the orders to your CSM Or tech point of contact and they can process them for you. See the Orders developer documentation for more information.

Note: Orders will default to Whiplash Cheapest Rate shipping method. If you would like to test the shipping method mappings, you can map your ship methods with help from our Parcel team.

Additional notes

• To test the ship notice receipts and shipped notifications, subscribe to the relevant webhooks, located here:
  https://app-sandbox.getwhiplash.com/notification_subscriptions.
• If you need any custom logic outside of defaults flows, you can configure rules by navigating to the Rules tab from your customer profile.
• Your implementation of each of the steps should check for the existence of the Whiplash object before your application creates it. For example, an item can only be created once and is shared by many orders.
• You can save your own order/item ID as the Originator ID, which will make it easier to look up your orders later. See the Originators developer documentation for more information. Using the Originator ID will also act as a safeguard to prevent your application from creating multiple copies of the same order/item.

Related API documentation

• V2 API Developer Library
• Authentication for the V2 API
• Searching in the V2 API

Other API versions

V2.1 API

The V2.1 API is almost identical to the V2. The critical difference is that it limits the size of the payloads we return. Applications that do not inspect our responses and use Status Codes can use the 2.1 API as a drop-in replacement.

Note: Calls to resources that do not implement V2.1 API will be forwarded to the V2.0 API. V2 requests are backward compatible and will not fail.

See the V2.1 API Developer Library for more information. 

V1 API

The V1 API is deprecated and no longer supported. 

Related questions: 

How do I find the API developer library? 

What steps are recommended when testing in the sandbox?