This section explains common terms used in our documentation, and also some of the common OAuth terminology we use.
This table explains some common terms used throughout our documentation.
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.
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.
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.
The Application Programming Interfaces provided by Shipium that bridge your existing frontend systems with backend operations.
Zebra Programming Language, a means of printing labels.
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.
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).
The actual username and password entered by the user.
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.
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.
The resource server hosts the protected user accounts. The authorization server verifies the identity of the user then issues access tokens to the application.
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.
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.
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.)
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.
The resource server handles authenticated requests after the application has obtained an access token.
Updated 10 months ago