How do their APIs compare?

Framing this properly: these two projects aren't really comparable at the "API" level in a like-for-like sense, since one is a Windows desktop application and the other is a rendering/graphics library for Unity. But here's what the repository data shows about each:

klocman/bulk-crap-uninstaller — no public library API

This is a WinForms desktop application, not a library. It doesn't expose a consumer-facing API; instead it's organized into internal functional modules that call each other directly:

• Functions/ namespace holds application logic split into static helper classes rather than a cohesive API surface — e.g. MessageBoxes for dialog prompts like LookForJunkQuestion() [source/BulkCrapUninstaller/Functions/MessageBoxes.cs:L169-L194] and QuietUninstallersNotAvailableQuestion() [source/BulkCrapUninstaller/Functions/MessageBoxes.cs:L341-L371], both of which read/write persisted Settings.Default values and return enum-like results (PressedButton).
• AppPropertiesGatherer extracts reflection-based property tables from uninstaller entries, e.g. ExtractCertificateInfo() which pulls a certificate off an ApplicationUninstallerEntry and reflects over LocalizedX509Certificate2 properties into a DataTable [source/BulkCrapUninstaller/Functions/AppPropertiesGatherer.cs:L95-L113].
• AppUninstaller.cs and EntryPoint.cs pull together many Klocman.* and UninstallTools.* namespaces, showing the app is composed of internal libraries (Klocman.Forms, Klocman.Native, UninstallTools.Factory, UninstallTools.Junk, etc.) rather than a single documented public API [source/BulkCrapUninstaller/Functions/AppUninstaller.cs:L1-L30], [source/BulkCrapUninstaller/EntryPoint.cs:L1-L24].
• RatingManagerWrapper.InitializeRatings() shows an internal async/threaded pattern for fetching remote data (user ratings) with local caching, not an external API contract [source/BulkCrapUninstaller/Functions/Ratings/RatingManagerWrapper.cs:L134-L176].

Note the RepoPilot signal here: the import graph reports 0 files parsed / 0 internal imports for this repo, so no computed cross-file dependency map is available to characterize how these internal modules interconnect — that assessment above is from the visible source only, not a verified full-project graph.

unity-technologies/postprocessing — a deliberate, documented extension API

This project does expose a designed public API, meant for other developers to extend with custom effects. The documentation lays it out explicitly:

• A settings class extends PostProcessEffectSettings and is tagged with the [PostProcess(...)] attribute to register it with the volume/stack system, exposing typed, serializable parameters like FloatParameter [Documentation~/Writing-Custom-Effects.md:L14-L42].
• A paired renderer class extends PostProcessEffectRenderer<T> and overrides Render(PostProcessRenderContext context), using the shared context.propertySheets/context.command.BlitFullscreenTriangle API to draw fullscreen effects [Documentation~/Writing-Custom-Effects.md:L14-L42].
• On the shader side, the API extends into HLSL via shared includes (StdLib.hlsl), macros for texture declarations, and a conventional VaryingsDefault struct contract that custom shaders are expected to consume [Documentation~/Writing-Custom-Effects.md:L125-L190].
• Built-in effects like Bloom and AutoExposure follow this same settings/renderer pattern internally, using [Range], [Min], [MinMax], [Tooltip] attributes on parameters for Editor integration [PostProcessing/Runtime/Effects/AutoExposure.cs:L32-L82], [PostProcessing/Runtime/Effects/Bloom.cs:L103-L125].
• Supporting utility APIs exist too, e.g. HistogramMonitor.Render() for compute-buffer-based histogram generation [PostProcessing/Runtime/Monitors/Histogram