Undelete365 is a web part that makes your site's recycle bin searchable and restorable — and it contains no code path that can permanently delete anything. That isn't a promise; it's a check the build fails without.
The problem
SharePoint's built-in recycle bin can't search or filter. It's one long list, sorted by deletion date — so finding the file someone deleted "sometime last month, I think it had budget in the name" means paging through everything deleted since then, by hand.
Undelete365 puts a search box, filters (name, original location, who deleted it, item type, date), and multi-select restore on top of the same bin — nothing more.
How it works
The safety audit
Every network call the application code makes lives in one file. Here is the complete list — the same table as the README, "destructive?" column intact.
No other endpoint is ever called by the application code. None of SharePoint's recycle-bin removal endpoints (DeleteByIds, EmptyRecycleBin, …) appear anywhere — not in source, not in the compiled bundle, not built from strings.
Every purchase includes verify-compiled-package.js — a dependency-free script that checks exactly what you were sent, not what you're asked to trust.
Who it's for
Approve it once in the App Catalog knowing exactly what it can and can't do — the permissions screen and the safety check are your evidence, not our word.
Hand your client's security team the network-call table and the checker script. The justification memo writes itself.
Find the file someone deleted last week and put it back — without opening a ticket or paging through the bin by hand.
Get started
undelete365.sppkg + the verifier script), built specifically for your tenant, is ready instantly on the confirmation page.FAQ
No. The application code contains exactly three network calls — two reads and one restore. None of SharePoint's removal endpoints appear in the source or the compiled bundle, and the included verify-compiled-package.js checks that against what you actually received. Restoring is itself reversible: re-deleting the item puts it back in the bin.
None to configure. It requests zero API permissions and uses the signed-in user's existing SharePoint session. Users can only see and restore what they could already see and restore in SharePoint's own recycle bin UI.
Each purchase is built to load its code only for the tenant it was bought for — so it can't be casually forwarded to a different company and just work there. It doesn't change what the app can do or what data it touches, only where its compiled code is allowed to load from.
That's SharePoint's rule, not ours — the second-stage (site collection) bin is admin-only by design. The web part doesn't elevate anyone: non-admins get a 403 from SharePoint, and the tab is simply hidden for them.
The restore for that item fails safely. Nothing is overwritten; the item stays in the recycle bin, untouched, and the list shows you the reason so you can rename or move the conflicting file first.
SPFx web parts only run on modern pages. On a classic-only site you can still use it via SharePoint's built-in hosted workbench (/_layouts/15/workbench.aspx) — same permissions model, no extra risk.