Tanner Stine: Really useful breakdown, thank you. All three are write operations and the current beta is read-only, so none are available today — but they're squarely in the direction we said we'd go after reporting and data access, and I've captured them as a tracked item rather than leaving them in this thread.

Quick read on each: Device Mode is the strongest of the three for us — one source of truth in your RMM is the drift problem we hear most. Agent deletion is probably the most self-contained; removing on uninstall instead of waiting out the inactivity window is a clean win. Technician Mode is the one that needs the most design care, since it has a deliberate verification step today and an API path shouldn't become a weaker route to the same privilege. Not a no — just the part we need to get right.

Worth noting your PSA use case overlaps with Brett's webhook ask — we're looking at those together.

Daniel Rivera Quick correction, technician mode can be set via the portal today without a verification step.

Tanner Stine: fair correction — no per-action verification on the toggle itself. Where the verification sits today is the portal login: getting to that Actions menu means an authenticated admin session with a role and an identity on the audit record.

So for an API path the question is how to carry that same assurance: which key scope grants it, whether it belongs in a limited-scope key at all, and what gets recorded as the actor when the caller is an integration rather than a person. Scoping and attribution rather than added friction — and we'd expect Technician Mode to come along with the other actions, not be the one held back. Tracked on our side.

Daniel Rivera That sounds reasonable. From my perspective, the API key/service account is the equivalent authentication boundary for an integration, with the key's scope handling authorization and the associated account/key identity providing attribution in the audit log.

Ideally, Technician Mode would therefore just be another permission that can be included or excluded from a scoped API key/service account, rather than requiring any additional per-action verification.

The responsibility then sits with the user to appropriately scope and protect those credentials, while the API provides the same functionality and controls that are available through the UI.

Josh D: That lines up with how we're thinking about it. The foundation is already per-user identity with scoped, expiring keys rather than a shared service account, so the natural direction is for authorization to come from the key's scope and the key's identity to carry through to the audit record — with Technician Mode as another scoped permission rather than a special case.

Write endpoints, including the three Tanner raised, are in active development as part of the next phase. We're still working through the details and some of it may shift as we build, but that's where we're heading. No date to share yet.

Brett Weese: Great to hear you got the API connected to Rewst, that's exactly the kind of integration we built it for. Webhooks are the natural next step, and outbound event delivery (including elevation request events) is something our team is actively exploring as a follow-on to the Partner API. Your use case is really helpful in continuing to shape this feature: firing an event to Rewst when an elevation request comes in, then driving the approval/denial workflow from there.

Scott Spivey: thanks for the detailed feedback, and fair point on the roadmap. The history here reflects when we updated the status, not when work began — and we know this has been anticipated a lot longer than that. Keeping this roadmap in step with our actual progress is on us, and we're fixing it.

Being straight with everyone following this thread: it was most recently targeted for Q1 '26 and we did push it. The reason was deliberate. Partner API access touches sensitive operational data, so instead of relying on shared service-account credentials we reworked the model around per-user identity with scoped, expiring API keys — least-privilege access with much tighter control over who can do what. We'd rather get that right than walk something back on security.

The good news is that work is now largely behind us. Read-only reporting is already built, and the team is moving quickly on the next layer. We expect to begin rolling this out in the coming months, starting with reporting and data access — which speaks directly to the billing reconciliation and reporting automation many of you have raised — with broader automation following close behind.

We hear the competitive pressure and the manual-billing pain, and we don't take either lightly. Appreciate you all pushing us on this.