# Unexpected REST API paths change in 1.32.4465.96

**URL:** <https://forum.pritunl.com/t/unexpected-rest-api-paths-change-in-1-32-4465-96/3828>\
**Category:** Pritunl VPN\
**Created:** [August 4, 2026, 9:48pm UTC](https://forum.pritunl.com/t/unexpected-rest-api-paths-change-in-1-32-4465-96/3828 "2026-08-04T21:48:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![andreym](https://forum.pritunl.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@andreym](https://forum.pritunl.com/u/andreym)\
**Post date:** [August 4, 2026, 9:48pm UTC](https://forum.pritunl.com/t/unexpected-rest-api-paths-change-in-1-32-4465-96/3828/1 "2026-08-04T21:48:51Z")

</div>

We’ve recently upgraded from 1.32.4400.99 to 1.34.4681.89,  
and noticed that this broke `/key/<org_id>/<user_id>` API,  
which started to return 404.

Apparently, it’s the following commit that landed in 1.32.4465.96 that moved some of the `/key/...` API endpoints to `/data/...`:

> <https://github.com/pritunl/pritunl/commit/5540ea534f34f17755b09fe2dbf88ddc894b9a6b>

```diff
-@app.app.route('/key/<org_id>/<user_id>', methods=['GET'])
+@app.app.route('/data/<org_id>/<user_id>', methods=['GET'])
 @auth.session_auth
 def user_key_link_get(org_id, user_id):

```

Is there a reason for this change?  
Is it possible to change it back or provide an alias for backwards compatibility?

In general, what are the expectations with regards to Pritunl REST API stability and backwards compatibility?

---

<div class="post-metadata">

**Author:** ![zach](https://forum.pritunl.com/user_avatar/forum.pritunl.com/zach/32/1105_2.png) [@zach](https://forum.pritunl.com/u/zach)\
**Post date:** [August 5, 2026, 5:01am UTC](https://forum.pritunl.com/t/unexpected-rest-api-paths-change-in-1-32-4465-96/3828/2 "2026-08-05T05:01:43Z")

</div>

This was done to add the external web process NaCl token request validation in **[Pritunl v1.32.4512.98](https://forum.pritunl.com/t/pritunl-v1-32-4512-98/3702)**. This adds an additional NaCl based cookie that allows the external `pritunl-web` process to validate a request before forwarding it to the root `pritunl` process where it then passes the standard session validation. Although this feature is less isolated when an API key is configured as the API keys can only be validate in the root process. This mode is indicated by `web_auth_strict=false` in the startup log message, it will still use the validation but the request will reach the root process where it will enforce the NaCl token check only for non-API key requests.

The problem was the other `/key` handlers are open for the client connection authentication and that one handler was an admin session so it needed to be seperated from the other `/key` handlers. This is visible in the [**pritunl-web/handlers/handlers.go**](https://github.com/pritunl/pritunl-web/blob/master/handlers/handlers.go). This has been the only breaking change to the API it’s unlikely other changes will be made.

---

<div class="post-metadata">

**Author:** ![andreym](https://forum.pritunl.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@andreym](https://forum.pritunl.com/u/andreym)\
**Post date:** [August 7, 2026, 1:52am UTC](https://forum.pritunl.com/t/unexpected-rest-api-paths-change-in-1-32-4465-96/3828/3 "2026-08-07T01:52:32Z")

</div>

Thank you for the explanation!  
It makes perfect sense.

> [@zach](#):
>
> This has been the only breaking change to the API it’s unlikely other changes will be made.

Yeah, it’d be certainly great to maintain API stability!  
Or, at least, mention backwards-incompatible API changes in the release notes.