Common Terms and Definitions

Overview

This section explains common terms used in our documentation, and also some of the common OAuth terminology we use.

Common Shipium terms

This table explains some common terms used throughout our documentation.

Term	Definition
Partner	A company or other organization which is working with Shipium to improve its fulfillment and delivery promise capabilities.
Customer or "Partner Customer"	A customer of one of Shipium's Partners. For instance, "The Shipium API is used by a Partner's software to provide a Delivery Estimate for their Customer."
Delivery Estimate or Estimated Delivery Date	The date on which a given product is expected to be delivered to a given Partner Customer.
Delivery Estimate ID	ID that is returned as part of the response from the Product View API. This ID is used to track a given product view through to order, shipment, and delivery.
Fulfillment Center (FC)	A warehouse which your stock is shipped from.
Fulfillment Context	Your organization may have different carrier accounts or other behavior changes within a single FC. 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.
Ship Option	A high-level description of a type of shipping that has been shown to a Customer. This generally describes a shipping time that the Customer has been told to expect, such as "Standard" or "NextDay", etc.
ShipTime APIs	The Application Programming Interfaces provided by Shipium that bridge your existing frontend systems with backend operations.
ZPL	Zebra Programming Language, a means of printing labels.

OAuth terminology

For convenience, some common OAuth terminology to which we refer is briefly outlined below.
For more details, please see Oauth 2.0 Servers.

Definitions below come from oauth.net, another excellent resource.

OAuth Term	Definition
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).
User Credentials	The actual username and password entered by the user.
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.
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.
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.
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.
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. (For programmatic access, refresh tokens are not used and a new token must be retrieved.)
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.
Resource Server	The resource server handles authenticated requests after the application has obtained an access token.