Previously, if you filtered a list by an xp, it only cared about items in that list that had that xp. This meant that negative filters, such as 

, for example, would only return other items 

 at all, it would not be returned in the filtered list.

Now, xp filters don't just look for the specified xp and filter down from there. Instead, a filter of 

 providing you the ability to publish these messages to the destination of your choice.

 allows you to synchronize your orders with the associated 

 mechanism of your choice. This way, you will be notified anytime an order is submitted and of any changes it incurs in the future. 

Webhooks can now be optionally configured to use the 

. This allows you to delivery their payloads to the delivery configuration mechanism of your choice.

 allows you to synchronize your catalog content with any system of your choosing using the pre-defined delivery mechanism that best suits your needs.

 is a new way you configure the location of certain types of messages within the context of OrderCloud.  These can include Known and Custom locations.  Custom locations allow you to have 100% control over the integration and allows you to deliver these messages to either an Https endpoint, Event Hub Namespace or a Kafka cluster.

Currently this new feature is leveraged by 

 which has been modified to leverage Delivery Configurations.

Please let us know if you have any questions. 

OrderCloud introduces Tracking Events for commerce solutions, offering analytical insights and infrastructure for targeted systems. For more information, see 

{
  "ID": "",
  "EventType": "UserLoggedIn" | "LineItemAdded" | "LineItemUpdated" | "OrderSubmitted",
  "ClientID": "",
  "Name": "",
  "ConfigData":""
}

multi-location inventory in OrderCloud Marketplaces

multi-language and multi-currency support in OrderCloud Marketplaces

New features to enhance flexibility around 

Products, Pricing, and Ordering in OrderCloud Marketplaces

This release contains a change to enforce the OrderCloud minimum password standards immediately for newly created organizations only. No changes for existing customers/organizations. As outlined in 

, OrderCloud-wide enforcement will still begin June 1, 2021.

Update how background jobs are queued and processed, as well as the removal of 

2 minutes of expected downtime occurred between 9:05pm - 9:07pm CST

There were no changes to the OrderCloud API, this was mainly in support of 

This release fixes an issue related to special-character encoding during authentication that affected a relatively small number of users but prevented them from authenticating successfully.

This release enforces some limitations on route access based on user type. Currently accessing these routes as the wrong user type can lead to unexpected/unintended results. Some of these limitations already exist today; however, all of them are listed below to provide a full overview. Please reach out in our Slack Community with any questions!

New endpoints and model properties related to forthcoming Integration Events feature:

This release adds the same Elasticsearch-driven 

. Initially, this will only affect a small group of beta customers, but we will be rolling it out to everyone in the coming days/weeks. 

 carefully, especially regarding the changes in 

, as it will now be relevant to "admin" product lists.

 Contact Four51 if you have any questions or concerns.

 both return a response that looks like this:

{
    "OutgoingOrders": [ ... ],
    "RemainingLineItemIDs": [ ... ]
}

This is the first of a series of feature releases expanding the capabilities of Suppliers in OrderCloud. It is part of a larger vision of enabling Marketplaces, where independent Suppliers (who typically own product catalogs) can interact with independent Sellers (who typically own relationships with Buyers).

Note that this is a redo of release 1.0.99, which included the items above but was rolled back due to performance issues. The cause of those issues has been identified and corrected.

Release consisted of a bug fix for Search 2.0 customers. We discovered that filter values using Search 2.0 were inadvertently case-sensitive. This has now been changed.

 will now return products with VOL, Vol, or any other case permutation in the Product Description or Product Name.

As this is a Search 2.0 related item, you will only see a different if your application is using Search 2.0. Search 2.0 is only enabled on the 

 continue to be case-sensitive, as they are properties of the product. Using 

 will return nothing, as those are not properties.

Previously, with filters there was no way to specify multiple fields and get results back when 

 match. This is now supported with syntax like:

 in the ID, Name, or Description. This functionality is currently limited to the 

 endpoint in orgs with Search 2.0 enabled. We're hoping that this will facilitate ease of transfer to the new search platform.

Several bug fixes and performance improvements, for apps using both the basic search, and Search 2.0.

Several bug fixes and performance improvements.

We've expanded Variant functionality! Variants are used to create versions of the same product that have different specs. For example, one product might have three different sizes available, small, medium, or large. Rather than have three different products, variants allows you to have one product with different arrangements of specs. Specs can also be open text entry, or include a markup. We've expanded variants to allow for variant-level inventory tracking.

We've gotten some more feedback from our beta group about what they want in this new Search, and we've changed some of our search weighting accordingly.

What Is It? You can now specify a Supplier in the 

 message sender assignments. This allows Supplier Users to reset their passwords using the 

 endpoint. Remember, you also have to make sure that the API Client you want to use allows Supplier Commerce Access!

How Does This Affect Me? This only affects you if you're using the Suppliers feature, and want Supplier Users to be allowed to reset their passwords.

Release consisted of minor bug fixes and performance tweaks.

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.

. 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.

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.

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.

, 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 

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 

 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 

 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 

, or a back-end integration to update your product catalog.

, assigning a default context user to an API Client that has multiple buyers, seller, or supplier accesses assigned to it allows access to 

 assigned seller, buyer, or suppliers. Thus, you 

 create an API Client ID with a seller, buyer, and supplier access and a default context user, but you 

, 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.

 call, the Supplier that the user has access to will be returned in the response body.

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.

 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

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 

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.

This will only affect you if you are using our 

 beta, and you have a number of facets > 50.

This release consists of performance enhancements and some minor model additions.

 property to LineItems that shows the SupplierID if the LineItem inherits one.

If your Product Catalog pre-defines Suppliers that a product comes from, you'll be able to see this information on Order LineItems. This may be useful to visually group or otherwise distinguish line-items by their shipping location.

We've added the ability to allow users to resubmit an order for approval.

If you use Order Approvals, you can run into situations where if the user just changed 

, it'd be an approved order. Maybe the buyer wanted 100 jars of bees by Tuesday, but you won't be able to fulfill the order that quickly. If the user gave you a little more time, they could get all 100 jars, or they could settle for the 60 jars you have in stock right now. With 

, you can allow users to resubmit an order after making the necessary changes, rather than make them build up a whole new order and check out again.

If you use Order Approval workflows, this could be very handy! As long as the order hasn't been submitted, you can go back and forth as long as you want with a user on an order.

API v1.0.72 Release Notes

Released on null

New Features