I’m trying to build a Catalog synchronization feature, and it occurs to me that the Catalog Upsert API call is a misnomer because you are required to use different IDs to distinguish between a create operation and an update operation.
This is problematic. We can use the temporary ID format to create an object and save the system generated ID for later. Meanwhile, the user deletes the object from the Square Catalog. We go to update the object using the system ID and this fails. By the way, it’s really annoying that the object not found error is returned as a generic 400 Bad Request error, rather than a more specific 404 Not Found error.
In order to solve this error, we need to catch the error, update the ID that we use to the temporary form and then retry the request. This is not really how an upsert operation is meant to work.
I believe that the API would be a whole lot easier to use if you allowed the use of user-assigned handles in the ID field. These symbolic IDs could be used to access the catalog objects without needing to know the underlying system ID. For example, we could create an item with an ID of “#Item_1234” and then use the same ID to update, retrieve or delete the item. If this could be done, then you would actually have a true upsert capability because the same ID could be used to create and update an item. If the item doesn’t exist, then it automatically creates it.
