V3 is a complete rewrite of the Dsco APIs from the ground up. What's different from V2 and why the rewrite?

Why the rewrite?

First, Dsco is adopting a new, even more modern architecture for the underpinnings of the Dsco API layer. This new architecture will allow Dsco to continue scaling as it has been, but more easily.

Second, over the last few years, Dsco has moved to a more streamlined architecture behind the scenes based on real-time stream processing. This change will allow the Dsco APIs to take advantage of the stream processing architecture and provide finer-grained APIs to support more specific use cases without sacrificing performance or scalability.

Finally, Dsco is seeking an opportunity to make a non-backward compatible change to correct some things that could be done better in a rewrite, and this is that chance.

What's different?

Model Objects

  • Most model objects used in the APIs will be almost identical with a few minor changes.
  • Dsco is ensuring a clean separation between inventory data and catalog data for items. Catalog data that was on the ItemInventory object has been removed.


  • Each API that allows a partner to send Dsco data will exist in multiple versions with Dsco implementing the Large Batch Update version of each first.
    • Large Batch Update
      • The API will accept up to 2 gigabytes of objects to be updated at the same time, but the API may only be called 10 times a minute.
    • Small Batch Update
      • The API will accept up to 5 megabytes of objects to be updated at the same time, but the API may only be called 10 times a second.
    • Single Object Update
      • This API will accept only a single object to be updated at a time and may be called 100 times a second.
  • Each API that accepts objects to be updated may choose to simply accept the data to be updated, and choose to process the data asynchronously.
  • Dsco will publish an API for each model object that may be updated that allows the developer to retrieve a log of all change that was attempted, allowing the developer to see any failures that may have occurred in case any asynchronous updates after the fact failed.


  • All webhooks that send notice of updates to model objects will now include additional information about what changed from the previous version of the object to the new one.
  • Webhooks will implement a more sophisticated and lengthy retry mechanism with less stringent requirements on timeouts to make webhooks more resistant to performance variability of the partner's infrastructure.
Was this article helpful?
0 out of 1 found this helpful



Please sign in to leave a comment.