Specify user by external id

Support
1

I’m just starting to learn how to use the Discourse API.

I’ve got data coming back when I send an api_key and api_username to an endpoint.

However, specifying the user by their username seems mysterious and brittle. I need to know the right username but the user can change their username and I don’t know what it actually is from outside.

My Discourse users can only import an account from my Bubble app. In the SSO section there’s an ‘external id’ that looks like it’s the account’s unique id from Bubble.

Is there a way to specify the user I want based on their external id instead of their username?

1 Like
2

/users/by-external/<id>.

2 Likes
3

It looks like that’s returning a webpage? At least the DOCTYPE is html

4

can you append .json to the end?

1 Like
5

So when using the api you can search for them by external_id, but you still need to reference their username in most api calls, like in order to get their notifications.

You would call this endpoint, and specify their username:

https://meta.discourse.org/notifications.json?username=<username>&api_key=<api_key>&api_username=system
6

Ah, okay, yes that returns json. It looks like a user’s profile information. I see the current username under user > username.

So do I have to lookup the current username based on the external id and then use the confirmed username in a second request?

Like, is there a way to use these parameters to get info in one request?
api_key
api_username
external_id (instead of username)

It seems weird to base requests on a field that can change instead of some system generated id field that never changes.

7

Correct, but you can cache it depending on what you are doing, so you don’t have to look it up everytime.

Nope.

Do your usernames change a lot though? I do kind of agree with you, but even if it was by id you would still have to look up the users id based on the external_id and use that.

I’m not totally sure though but some endpoints might take either one (username or id), I know this isn’t a user endpoint, but for example the topic endpoint you can do something like this and leave out the slug:

https://meta.discourse.org/t/-/87383.json

I digress though, since most endpoints do key off of the username.

2 Likes
8

Thanks. I think I can work with that.

Is there a way to get the current number of unread notifications? Like the number that displays in Discourse? I want to display that number back in the Bubble app so users know to check the forum.

It looks like what’s returned from notifications.json is a list of notifications?

Does Discourse have an immutable id for each account? I guess I just assumed it would since that’s how everything I’m familiar with works.

9

You should only need varying api_username when you’re acting “as” varying users.

You should be able to pull notifications for other users by loading /notifications.json?silent=true&username=abcd&offset=0 from an admin account.

(note: silent=true prevents your automated code from marking everyone’s notifications as read/seen)

7 Likes
10

It makes sense that api_key and api_username are for authentication and then “username” is to identify the user I’m interested in.

Is there a way to get the total “unread” notifications?
Does that have to be calculated from the list of notifications and the seen_notification_id?

11

To get the blue/green numbers, load /session/current.json as the desired user.

,"unread_notifications":0,"unread_private_messages":0,

1 Like
12

Oh, cool! Thanks.
Okay, so it looks like that endpoint is only giving me my session info. The info for the username in api_username. When I add another “username” parameter it seems to be ignored.
This sounds similar Session/current always returns api_user

Is there a better way to discover this stuff than bothering people in the forum?
docs.discourse.org looks pretty sparse, like I can’t even find that “session” endpoint when I search for it specifically.

13

Please checkout this topic:

and also looking at the source code for the controller of the endpoint you are trying to hit is very helpful:

This is because that endpoint doesn’t have support for a “username” param.

:cry:

The api docs could use will always need some work, but they do document most of the heavier used endpoints. If you find a new one we would very much appreciate the help of the community to help document it. I will keep trucking along myself though and continue to document things at a :turtle: steady pace as time permits.

image

I’m not familiar with Bubble. Is this what you are referring to?

https://bubble.is/

Either way, Discourse by nature has an api endpoint for most things, but that doesn’t necessarily mean that it will always be super friendly when you are trying to call things from external sites instead of natively from inside Ember with a logged in user cookie. This may mean that it will be more productive to write a custom plugin or use the data explorer plugin to write a custom query and then make an api request to that saved query. Also PR’s are always welcome to improve something.

6 Likes