Catalog API Introduction

PSS has always dedicated itself to lowering the barrier of entry into online commerce at a large and competitive scale for the Powersports industry since its inception. As our customers needs continue to grow and their integration requirements outpace what our internal development cycle can confidently and reliably deliver in a timely manner we offer this API to leverage our catalog data and in turn our marketplace and external application integrations to allow for a single, unified communication hub for programmers to develop against.

By implementing the PSS API our customers’ developers do not need to worry about the added overhead of maintaining the requirements of multiple marketplaces and any additional software they may use that PSS supports, PSS will act as a communication intermediary for the software & marketplaces we already implement and relay the appropriate data to the appropriate endpoints.

The use cases outlined below are just a small sample of what can easily be accomplished by implementing the PSS API.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

Document Definitions & References:

  • Catalog API - The PSS provided server endpoint(s)
  • Catalog Data - The data offered to the Client Application via Catalog API
  • API Client - PSS Provided API client that can be used to test requests against the Catalog API
  • Client Application - Client application used to communicate with the Catalog API
  • End User - The user the Client Application is being developed for, this is typically a user that interacts with PSS through the use of the PSS Dashboard
  • PSS Dashboard - The End User facing application hosted by PSS
  • Development Team - More than likely the person(s) taking the time to read the Document Definitions & References

Feedback and Knowledge Base