API v1.0.85 Release Notes
Released on null
Summary
This release consists of both a new API version, v1.0.85, and an update to our DevCenter site. We are reorganizing our conception of what an 'application' is around API Client IDs. This release contains the beginning of that process, supplier-related improvements, and other performance improvements, bug fixes.
Updates
API Client Unification
What Is It?
We've replaced the idea of Buyer Networks, Buyer Apps, Seller Networks, and Seller Apps with, instead, just the API Client ID. Instead of talking about multiple apps with API client IDs attached to a Buyer, we now have multiple API Client IDs with a Buyer Commerce Role.
Why Is It Important?
When you create a Seller API Organization in OrderCloud, you are creating a little world where data like products, users, and other concerns can be shared and configured in various ways. Within this little world, there might be many applications, such as the app where your CSR users log in to manage bulk orders, the app where the general public can buy your most excellent product, or an app where your users can buy things from your company, and you can then buy those products from other supplier companies.
The base unit of this world is the API Client ID. This ID identifies what context a user is authenticating into. For example, Allison may be one of your CSRs, but she also manages your product catalogs in a catalog management application. When she logs in, the different API Client IDs used in her authentication set the context that she is working in, and what data she has access to.
How Does This Affect Me?
This change should not impact your existing API organizations and API Client IDs/apps. All existing applications have been migrated to the new API Client ID + Commerce Role Access schema. The Commerce Roles are made up of the three distinct user types that exist in OrderCloud-- a Buyer User, a Seller User, and a Supplier User.
However, when you log into the OrderCloud Portal, you will immediately notice the difference.
When you go into DevCenter and view one of your Seller Organization, you'll now see API Clients in the side menu rather than seller applications/buyer organizations/buyer networks.
Under API Clients, you'll see all of those applications listed by API Client ID. Each will have the assigned commerce role accesses displayed as well.
What will likely be the most common is having one Commerce Role assigned to an API Client ID. This would be the typical situation of having one application for your admin users to manage orders, catalogs, etc, and one for your buyer users to log in and make orders, etc.
However, perhaps you want to have one web page, one application where both your buyer users and your admin users can go. One API Client can have multiple commerce access roles to accomplish this.
When your admin user authenticates, the front-end application will show the admin different options than your buyer users will see. This puts the onus of separating functionality visibility on the UI, likely checking user security roles to show or hide functionality.
Notably, you can assign all buyers in a Company Organization to an API Client ID, or only specific ones.
Finally, you can assign a Default context user to an API Client ID. This defines a user that acts as a template for client credential access to the site. The template user sets what security profiles and things like addresses, products, etc that an unauthenticated user will have access to. This allows things like anonymous shopping, or a back-end integration to update your product catalog.
Please note, assigning a default context user to an API Client that has multiple buyers, seller, or supplier accesses assigned to it allows access to all assigned seller, buyer, or suppliers. Thus, you can create an API Client ID with a seller, buyer, and supplier access and a default context user, but you really probably shouldn't, unless you really really want that Default Context User to be able to have access, however limited, to all your buyer, supplier and seller information.
Supplier ID on Me Buyer-Endpoint
What Is It?
When a user performs a buyer-endpoint ME GET call, the Supplier that the user has access to will be returned in the response body.
Why Is It Important?
If you use Suppliers within your applications, being able to identify which supplier a user has access to without giving extra permissions to a user is helpful.
How Does This Affect Me?
This will be present on all /me response bodies but will be null unless the user has access to a supplier.
Search 2.0: Faceted Navigation Allowed to Return up to 50 Facets
What Is It?
Pretty much what it says on the tin, the facets returned on a [me/Products]'s response body can number up to 50. If you have more than 50 facets that apply to a user, the first 50 will be returned, based on listing order.
Why Is It Important?
This was requested by several of our Search Beta users, as it allows them to give their users a more detailed faceted navigation filtering experience.
How Does This Affect Me?
This will only affect you if you are using our Search 2.0 beta, and you have a number of facets > 50.
Bug Fixes
Minor bug fixes.
Performance Improvements
We included some more aggressive clean up of product caches for searching.