Partner API: Add a Write Endpoint for Elevation Rules (PUT/PATCH)
in progress
Doug Yowell
The Partner API can read elevation rules but can't modify them. We can audit and pull all elevation rules in a tenant, but have no way to make changes at scale — every edit has to be made one by one through the GUI.
Request: add PUT/PATCH /api/v1/elevation-rules/{id} behind a ruleEdit scope.
Today, /api/v1/elevation-rules is GET-only — no PUT, PATCH, or POST, and no /elevation-rules/{id} route at all. So a partner can enumerate a rule estate and detect problems programmatically, but can't act on anything it finds.
For an MSP with a few hundred clients, that's thousands of rules across a single AE tenant. When a mass change is needed, editing them one at a time quickly becomes impractical.
D
Daniel Rivera
updated the status to
in progress
Update: this is now in active development. Hi Doug — following up on the questions from our last exchange. Here's where we landed: write access to elevation rules is being delivered as part of Partner API phase 2, which is in progress now. What's coming: PATCH /api/v1/elevation-rules/{id} behind a dedicated ruleEdit scope (the scope you suggested), letting you update a rule's action, elevation type, audit-mode flag, friendly name, notes, and identification criteria. Changes made through the API are audit-logged with full attribution, and the ruleEdit scope will be selectable when you create a limited API key. A couple of decisions worth being upfront about: we're shipping PATCH only (PUT would have added no capability over partial updates), and this phase is per-rule rather than batch — scripting against the endpoint is the intended path for changes at scale. We'll post here when it's live. Thanks again for the detailed request — it directly shaped this.
D
Daniel Rivera
updated the status to
under review
Hi Doug — thanks for the detailed writeup. You've described the current state exactly right: elevation rules are read-only in the Partner API today, which was a deliberate starting point for the initial release. Write access is a natural next step, and your MSP-scale scenario — auditing thousands of rules programmatically but having to fix issues one at a time in the GUI — is a strong case for it. We're marking this Under Review while we scope what safe write access should look like: a dedicated edit scope like you suggest, audit logging on API-driven changes, and guardrails around mass modifications. Two questions that would help us shape it: which rule fields do you most often need to change at scale (action, scope/level, criteria)? And would batch operations matter to you, or is per-rule PUT/PATCH enough if you can script against it? Thanks for pushing the Partner API forward — requests like this directly shape what we open up next.