PUT requests to XWiki REST API consistently return 401, while GET succeeds (same account, same token)

XWiki version: 16.10.17 (self-hosted)

Issue: I’m trying to create/update pages via the XWiki REST API using an OAuth2 Bearer token generated through XWiki’s Application/API token page (tied to an account with full admin rights). GET requests work perfectly, but PUT requests to the same space consistently fail with 401 Unauthorized.

What I’ve tested and ruled out:

  • Confirmed the token is valid — GET requests using the exact same Authorization header succeed and return correct data.
  • Reproduced the failure identically across three separate tools: curl, Postman, and n8n (an automation platform) — ruling out any client-specific issue.
  • Tested with and without a request body (form-urlencoded with title/content fields, and also with no body at all) — same 401 either way.
  • Tested with the XWiki-Form-Token CSRF header included (obtained from a prior GET response, per the documentation) — no change in outcome.
  • Generated a completely new token and re-tested — same 401.
  • Confirmed the account has full admin rights, and even explicitly verified/added Edit rights via the space’s Users & Rights panel.
  • URL structure matches the documented pattern exactly: /rest/wikis/xwiki/spaces/{space}[/spaces/{nestedSpace}]*/pages/{pageName}, confirmed valid since GET against the identical URL succeeds.

Hi,

I haven’t been able to reproduce your issue, so just to be sure: when trying with curl, what’s your full command? In my case, using a freshly generated OAuth token, on a local instance, this works without problem:
curl -H "Authorization: Bearer <fullTokenIncludingUserResource>" -H "Accept: application/json" -H "Content-Type: application/json" -d '{"title": "Hello World"}' -X PUT localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome2

A few things to note:

  • Without more information, a GET request working might not help debugging this. If the page is publicly available (allowed for Guest), you would still have access to it even with an erroneous/missing token. If the token is there but wrong, however, the server should log an Authentication error.
  • Since you mention your instance is self-hosted, there’s also the possibility you might be using a reverse proxy that’s stripping some of your request’s header, including Authorization.