Hello, I’m running into something on a Web Services SaaS source (target requires a full-object PUT, no PATCH) and wanted to check if I’m missing an easier way to do this.
Used a customizer’s beforeStdAccountUpdate hook to fetch the current account and backfill any attribute that isn’t part of the actual change, so the operation body’s $plan.x$ placeholders resolve instead of coming through blank.
Tried it for Enable, Disable, and Add/revoke Entitlement and it doesn’t work, even when I confirmed via logging that the customizer was returning the right values (backfilled changes array had everything, correctly populated), the target still rejected the request with required fields blank. Dug into the SDK types and StdAccountEnableInput/StdAccountDisableInput genuinely don’t have an attributes field at all, so there’s nowhere for that data to go on those two. Add Entitlement does route through beforeStdAccountUpdate and still doesn’t work, which I can’t fully explain.
Also tried the newer endpoint-level isBeforeCustomizer / customizedOperation(‘X:before’, …) approach, hoping to just rewrite _requestConfig.body directly, but at that point input doesn’t have the account identity at all, so I couldn’t use it for per account data.
What ended up working: have the hook do the actual write itself (GET the account, merge in the one real change, PUT directly), and change the native Enable/Disable/Add Entitlement HTTP operations from PUT to GET so they just refresh the account instead of trying to write with placeholders that don’t resolve.
It works, but it feels like a workaround rather than the intended way to do this. Has anyone hit this same limitation, or is there a cleaner supported approach I’m missing?
