Sign-up questions FAQ
OAuth 2.0 FAQ
Getting Started FAQ
Third Party Quoting Platforms FAQ
For mass seeding of product data including long descriptions, dimensional information, access to spec sheets or images, we recommend pulling information from a master product catalog that contains all active SKUs. The product hierarchy/category fields are a good way to organize similar items and view items already in your database and add potential new product lines. When you have an existing product database and you simply want to pull updated information, or create a service to present data to a user you do not wish to store you can leverage the Product Detail API. Note that the image and spec sheet URLs are do directories with files contained within and are not to specific image files. There may be multiple of each available.
Master product data is available via FTP.
File name: master.txt for basic product data
File name: master_na_enhanced.txt for over 35 fields of product data including image directories and dimensions
Many product availability inquiries seem to be done in batches, and a good majority of the items in each request won't be interacted with by someone on your side. We all want to provide the latest information to our users, but at what technical debt do large batch API requests or flat file imports come with? Use one of our product inventory files if you are looking for mass product availability updates. The pros is that you can update the inventory position on an large number of items. The con is that the data in the file is from a moment in time. Setting up an availability inquire on a smaller number of items is more efficient, real-time and can be done at the point of transaction. You may not even store the value after the user has closed their process. You can see an example of this by using our ecommerce portal. An API call is done to return real-time pricing and availability with each search or cart for checkout. Customers benefit by knowing real-time availability versus a cached or dated value in a table.
Hourly Inventory File published from 9 AM EST to 9 PM EST via FTP:
File name: InventATP1710.txt
Start by making sure any test purchase orders are sent to our sandbox environment and not to production. The basic purchase contains a PO#, ship to address, shipping method, and a lines array with items and quantities. Not all solutions are created equal and therefore we accommodate the many fields needed by our sales teams to complete your order with our distribution center or with one of our suppliers. The goal is a zero-touch order maximizing the speed to process your order. All API orders immediately create an order. Not passing a correct shipping method, vendor required data in the Answers array or special pricing details can delay the release of your order. Ensure all of the data is there increases the likelihood the order will go straight to processing.
Refer to the Sales Order FAQ for more insights.
We provide tracking and serial numbers in several of our responses allowing you the flexibility to architect what works best for your platform. A simple GET/tracking call with a customer number and PO or sales order number parameter returns tracking information for a quick point of inquiry solution. A use case could be someone interacting with a purchase order or sales order in your environment looking for the tracking and carrier. The drawbacks are back orders and storing this information to solve more than one use case. Partners rely on the GET/invoice/list with date parameters to return an array of orders invoiced since their previous requests. Then can then store the values to feed their own billing process, notify partners via ASN or other tools. The detail call for each invoice is also used to return more data that you might need.
Similar to the invoice list, GET/salesorder/list allows you to confirm that we received your purchase order. All documents are visible even if the order was passed in via EDI, our ecomm portal or entered by our sales team. Digital orders obviously allow you speed and accuracy, but they also allow you to pass in extra data you can use for downstream order processes like confirmation, ASN and billing. Pass in the parameters for lastChangedDate and Status to narrow results. Use the Order Detail request to return all the data we have on your order. Back order expected ship dates, pricing, shipping method, ASN information and billing information is provided in this single response.
Batch vs. On Demand vs. Web Hook
Depending on your user preference and use case, an on demand approach may be enough. Someone wants to know the status of an order and you make a quick request to pass in the order number to return a dialogue with the information they need to complete a task. If you have no need to store the data for other processes, this might work for you.
A batch job is efficient to store and update your systems for many orders. These do not need to be hourly. In most cases can be run once per day in the middle of the night once we have shipped, billed and updated back orders with expected ship dates as we have received updates from suppliers. Keep in mind date and order status parameters are important to limit the response from getting out of control.
A web hook subscription against an event grid is more efficient than a batch job. If you want to be informed when an order ships and you can query on shipping or billing information, our web hook triggering on order status may work. We will post to your server when a sales order/purchase order has a status change. A status of Partially Shipped or Completely Shipped are typically used by partners to trigger a request for tracking or billing requests.
Web Hook FAQ