Terms and Definitions
Learn definitions for Shipium's common terminology.
About Shipum terms and definitions
This section explains common terms used in our documentation, and also some of the common OAuth terminology we use. OAuth is an authentication protocol that allows users to approve one application interacting with another on their behalf without having to use a password.
Common Shipium terms
This table explains some common terms used throughout our documentation.
Term | Definition |
---|---|
Application Programming Interface (API) | A software interface that enables two or more computer programs to communicate with each other |
Carrier Selection | Shipium Carrier Selection APIs are called at the moment of pick-and-pack in order to return the best shipping label for a shipment. |
Customer or Subscriber Customer | One of your organization's customers (a customer of one of Shipium's partners); for instance, when you provide an estimated delivery date for a product on your website, you're displaying this information to your customer. |
Delivery Estimate or Estimated Delivery Date (EDD) | The date when a given product is expected to be delivered to your organization's customer |
Delivery Estimate ID | ID that is returned as part of the response from Carrier Selection. This ID is used to track a given product view through to order, shipment, and delivery. |
Delivery Promise | Shipium Delivery Promise API provides the best estimate of a shipment's delivery date. |
Desired Delivery Date (DDD) | The predicted date given from Carrier Selection at shipping time |
Fulfillment Center (FC) | A warehouse from which your stock is shipped |
Fulfillment Context | Your organization may have different carrier accounts or other behavior changes within a single fulfillment center. For example, you may have multiple carrier accounts in order to simplify accounting if you ship both on your own behalf and for 3PL customers/other partners. To handle this, the APIs use the Fulfillment Context. This enables Shipium to use the appropriate carrier accounts, settings, etc. within a given API call, based on assigned "contexts" for entities such as a carrier account. |
Limited Quantity (LQ) | A diamond-shaped symbol that is applied to packages to indicate that the products within the combination packaging are dangerous goods that are packaged in accordance with the Limited Quantity exemption (i.e., hazmat) |
Order Management System (OMS) | Utilized for order entry and processing |
Origin | Origin shipping fulfillment center |
Partner | An organization that has Delivery Promise, Fulfillment Engine, Carrier Selection, Label Service, and/or Track and Trace services contracted with Shipium |
Ship Option | A high-level description of a type of shipping that has been shown to your customer; this generally describes a shipping time that your customer has been told to expect, such as "Standard" or "Next Day". |
Tenant | A customer on whose behalf your organization provides shipping services |
Third Party Logistics (3PL) | Shared/externally managed warehouse location or company |
Track and Trace | Track and Trace takes a carrier identifier in addition to one or more carrier tracking IDs for that carrier, and conducts a boolean query to either request (a) the current status of the package(s), or (b) the current package status along with a full package tracking history. The API then returns the latest details and (optionally) requested historical details. |
Transportation Management System (TMS) | A software system utilized to manage physical goods transport logistics |
Warehouse Management System (WMS) | Utilized for inventory visibility and supply chain operations |
Zebra Programming Language (ZPL) | Most common shipping label encoding method |
OAuth terminology
For convenience, some common OAuth terminology is briefly outlined below. Definitions below come from oauth.net .For more details, please see Oauth 2.0 Servers.
OAuth term | Definition |
---|---|
Access Token | The element that applications use to make API requests on behalf of a user; the access token represents the authorization of a specific application to access specific parts of a user’s data. |
Authorization Server | The resource server hosts the protected user accounts. The authorization server verifies the identity of the user, then issues access tokens to the application. |
Client | The application that wants to access the user’s account; before it may do so, it must be authorized by the user, and the authorization must be validated by the API. |
Client Credentials | Applications themselves have to be authenticated and have their own credentials (e.g., username and password). This is to stop third parties from gaining access. |
Grant Type | This is used to tell the Authorization server the type of workflow it will run to verify the credentials. Password and refresh_token, respectively, are used to get a new token or refresh one that has already been released. |
Refresh Token | The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired. This allows clients to continue to have a valid access token without further interaction with the user. Note: For programmatic access, refresh tokens are not used and a new token must be retrieved. |
Resource Owner/User | The user who authorizes an application to access their account; the application’s access to the user’s account is limited to the scope of the authorization granted (e.g., read or write access). |
Resource Server | The resource server handles authenticated requests after the application has obtained an access token. |
Token Store | Tokens that have been released may be used across many systems. They are stored in a central easy-to-look-up location, or Token Store, behind the scenes of an API. |
User Credentials | The actual username and password entered by the user |
Resources
Your Shipium team member is available to help along the way. However, you might find these other resources helpful:
Updated 6 months ago