Inconsistency in Webhook Event Triggers: FOLDER.TRASHED vs. FOLDER.RESTORED for Nested Folders

I am currently developing an integration that relies on Box webhooks to maintain a synchronized state between Box and my application’s internal database. I have encountered a discrepancy in how Box triggers events for nested folder structures during trash and restore operations.

Observed Behavior:

• Deletion: When a parent folder containing multiple sub-folders is moved to the trash, the Webhook API correctly emits a FOLDER.TRASHED event for the parent folder, followed by individual FOLDER.TRASHED events for every nested sub-folder. This allows my application to accurately update the status of each item in my database.
• Restoration: When I restore the parent folder from the trash, all nested sub-folders are correctly restored in the Box UI. However, the Webhook API only emits a single FOLDER.RESTORED event for the parent folder. No events are generated for the sub-folders that were restored as part of that tree.

Technical Impact: Because my application relies on individual events to trigger status updates in my database, this inconsistency causes a "desync" where the parent folder is marked as "active" in my system, but the sub-folders remain marked as "trashed" or "deleted."

My Questions:

1. Is the lack of cascading FOLDER.RESTORED events for sub-folders intended behavior by the Box API?
2. If this is standard behavior, what is the recommended architectural pattern to handle this? Should I be performing a recursive API call to verify the status of children whenever a FOLDER.RESTORED event is received for a parent?
3. Are there any specific event types or configurations I might be missing that would trigger notifications for the entire restored tree?

Any insights or recommended best practices for handling this synchronization would be greatly appreciated. Thanks!