Discourse API Documentation

The way I read that is the app can’t figure out how to process the array with new lines into an array. Have you tried sending the request with the line simply as "post_ids": 925 or "post_ids": { 925, <other id>, ... }


Thanks, Justin. I have got a bit further by reverse engineering the change owner dialog in discourse. Apparently the json should be:

  "username": "sean-finnegan",
  "post_ids[]": 925

I have no idea how you should supply multiple post_ids - I imagine numbers separated by commas, but as the html version doesn’t allow you to change multiple owners at the same time, I am just guessing.


It seems that this change is enabled in 2.4.0.beta7 although I don’t find it announced in the release notes (I would assume that searching for “header” in posts tagged #release-notes finds it but it does not: Search results for 'header tags:release-notes order:latest' - Discourse Meta) [my mistake, the 403 invalid_access errors had another cause]

Thanks for alerting us with generous advance on this breaking change, but people are lazy so I bet you’ll get a lot of hits on this page !


@blake Do I understand correctly that this will disable the ability to use protocols like rss and webcal for private forums?

Currently rss and calendar clients can subscribe to private forum’s rss or webcal using api keys provided as part of the URI: https://forum.url/latest.rss?api_username=username&api_key=key.

Is it possible to exempt such protocols from header based authentication? I’m depending on rss and webcal functionality on my private forum.


Just noticed the deprecation warning:

  • We detected an API request using a deprecated authentication method. Please update it to use header based auth.

Anybody know when it is going to be removed completely? (i.e how long have we got before we need to update?)

Great to see there’s a Discourse api gem btw! Should make things a lot easier :smiley:


We don’t have a specific timeline set for this. At minimum a month or two, could be longer.

Thanks for bringing this up. We are considering some options to keep support for private rss and such in some way.


After having lost half a day chasing the rabbit :slight_smile: I want to share one subtle change that goes on top to moving api_key and api_username into the header of the request.

Parameters names in the request payload (deprecated)

api_username, with an underscore
api_key, with an underscore

Parameters names when used in the Header

Api-Username, with hyphen (or dash)
Api-Key, with a hyphen (or dash)

For me this was almost impossible to see, and I banged my head against the wall countless times fighting 403 [BAD CRF] error before spotting that we moved from underscore to dashes.

You out there don’t laugh at me :stuck_out_tongue:


Never! :rofl: Many of us have had similar “experiences.” :innocent:


Would it be possible to add a private access key similar to how reddit’s private feeds work? That would be the simplest solution I would think.

1 Like

Does the HTTP header based authentication has strictly the same behavior? I remember when the HTTP headers were available I tried them and I got weird behaviors where sometimes it did not work as expected. I know it’s vague, but I had no time to investigate back then. I’m just worried that since we are forced to update all our code, new issues will arise suddenly.

1 Like

Yes. Nothing else should change behavior wise. Just need to move the location of the api credentials.

Maybe you are thinking of the User API keys specification? Which is different than just using the full api.


Thanks for pointing this out, though, it wasn’t enough to entirely prevent my head-banging. Apparently remembering this and enacting it are two different things. :wink:


I’m getting the warning about authentication in the admin dashboard. I do have an API key which is being used every couple minutes, but I don’t know of any process that should be using it. How can I find out what the API request was, or maybe what IP it’s from? I don’t see anything in the logs.

EDIT: It may be SSO with Wordpress- will look more later.

1 Like

After seeing when the API was last used, you could try switching to Users to see if there have been any logged in (last seen) within the same time frame. That may be a quick way to help verify if it was SSO using it.

If you are using an up to date version of the WP Discourse plugin for SSO, it should not be the cause of the warning.


Sorry, I’m not a WP guy. This screenshot is from /wp-admin/plugins.php. There is no button to update, so I think this means it’s using v1.9.7, which matches the latest version at Releases · discourse/wp-discourse · GitHub.

So the question remains how to tell what process or IP is using that API key.

1 Like

You can grep the nginx logs for api-key and get its ip number, which might be a hint.


I have a API deprecation notice but have no clue what’s causing it. We have the WordPress / Discourse plugin installed (and up-to-date) but according to the dev this should not cause the notice. How do i find out whats causing this notice?

1 Like

Do you have any api keys listed under the admin / api section? Are they different than what the Wordpress plugin is using?


Yes, one for “all users” as is suggested (with publishing name set to “system”) and one for an admin account. I’ve tested both in WordPress, and turned them on/off in Discourse but tthe notice remains.

1 Like