Common Terms and Definitions


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.

PartnerA 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 DateThe date on which a given product is expected to be delivered to a given Partner Customer.
Delivery Estimate IDID 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 ContextYour 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 OptionA 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 APIsThe Application Programming Interfaces provided by Shipium that bridge your existing frontend systems with backend operations.
ZPLZebra 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, another excellent resource.

OAuth TermDefinition
Resource Owner/UserThe 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 CredentialsThe actual username and password entered by the user.
ClientThe 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 CredentialsApplications 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 ServerThe resource server hosts the protected user accounts. The authorization server verifies the identity of the user then issues access tokens to the application.
Grant TypeThis 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 TokenThe 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 TokenThe 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 StoreTokens 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 ServerThe resource server handles authenticated requests after the application has obtained an access token.