API: GetSheet (with rowsModifiedSince param) should be able to return information about deleted rows

srmoore

My use case and issue:

With the Smartsheet API, I am caching a sheet locally and using the rowsModifiedSince query parameter to only update rows that have been updated since the last time the cache was updated. This is a great performance optimization, however, if a row is deleted from the originating Smartsheet, no information about the deleted row is returned from the query. This means I have no way to know I need to update the cached sheet and remove the deleted row, and degrades the integrity of my cached sheet.

Proposal:

The Get Sheet API call should be able to return information about deleted rows. This could be parameterized in some way (includeDeletedRows in the query or something), and for my purposes it'd be fine if the deleted row was returned as a normal row with entirely blank cells for each column, although this may not be the ideal general solution. Currently the best I can do is retrieve every row for a single column, pull out all the current row IDs, and check this against the cached sheet - it technically works, but it slows things down a lot, hurting my original performance optimization.

Lee Joramo

I see the value of this.

I think WebHooks could be a way to deal with this by setting up a WebHook that is triggered on row delete, and allowing you to immediately clean up your local system. While I have used WebHooks, I have only needed to use triggers for creation and modification events, so there could be some issues with using WebHooks with deleted rows.

Even if WebHooks help with this use case, I still think your request is valuable. I typically do not trust WebHooks to always work. So I typically, use an automated process via the API to periodically perform the tasks that should have been handled by the WebHooks.

Note: my lack of trust in WebHooks is not to mean that there are any problems with Smartsheet's implementation. But it is a process that is beyond my control, and I can not restart it on demand. I could see many ways to make my systems responding to WebHooks more robust, but it is much more efficient for my use case to make sure that I can always clean up after any missed WebHooks.