uloggdDevelopers
Developer portaluloggd
Get startedResourcesArcade
Developer portaluloggdIdentityCatalogProfileLibraryReviewsJournalListsAwardsScreenshotsSocialAccountNotificationsCommentsLikesHistoryPeopleMineralsArcade

Social

Who the owner is connected to.

This scope says who, never what those accounts hold.

Requests to follow a private account are answered one at a time at /api/v1/social/follow-requests/{username}, or all at once: PUT /api/v1/social/follow-requests with {"all": true} accepts, and DELETE /api/v1/social/follow-requests?all=true declines. all is required on both, because an emptied queue does not come back.

GET/api/v1/social/followers

Accounts following the owner.

Scope social.read · Counted against the read allowance

GET/api/v1/social/following

Accounts the owner follows.

Scope social.read · Counted against the read allowance

GET/api/v1/social/blocks

Who the owner has blocked. The other direction does not exist: an account reads the blocks it made, never the ones made against it.

Scope social.read · Counted against the read allowance

Query

FieldTypeNotes
pageinteger1 to 1000.
qstringFilters by username or display name.
PUT/api/v1/social/following/{username}

Follow an account, or ask to if it is private. The answer carries following and requested, and only one of them is true. Doing it twice changes nothing.

Scope social.write · Counted against the write allowance

DELETE/api/v1/social/following/{username}

Unfollow an account, or withdraw a request that has not been answered.

Scope social.write · Counted against the write allowance

PUT/api/v1/social/blocks/{username}

Block an account. That also undoes following in both directions, which is the database's doing rather than this route's.

Scope social.write · Counted against the write allowance

DELETE/api/v1/social/blocks/{username}

Unblock an account. Following is not restored on its own.

Scope social.write · Counted against the write allowance

GET/api/v1/social/follow-requests

Who has asked to follow a private account and is still waiting. Only that direction exists: what this account has asked of others is their queue to answer, and listing it here would be reading a decision nobody has made.

Scope social.read · Counted against the read allowance

Query

FieldTypeNotes
pageinteger1 to 1000.
qstringFilters by username or display name.
PUT/api/v1/social/follow-requests

Accepts every waiting request at once and says how many: {"data": {"approved": 3}}. Each one is accepted as the single-request route would, with the same second-factor check when the account requires it. Without all: true in the body it answers 400, because emptying the queue cannot be undone and should not happen by mistake.

Scope social.write · Counted against the write allowance

Body

FieldTypeNotes
allrequiredbooleanMust be true.
DELETE/api/v1/social/follow-requests

Declines every waiting request at once and says how many: {"data": {"declined": 3}}. Without ?all=true it answers 400, for the same reason as the PUT.

Scope social.write · Counted against the write allowance

Query

FieldTypeNotes
allrequiredbooleanMust be true.
PUT/api/v1/social/follow-requests/{username}

Accepts a request. An account that was not waiting answers 404 rather than a silent success: approving a request that was withdrawn should not read as approved.

Scope social.write · Counted against the write allowance

DELETE/api/v1/social/follow-requests/{username}

Declines a request. It leaves the queue either way; only accepting creates the follow.

Scope social.write · Counted against the write allowance

POST/api/v1/reports

Tell moderation about something. There is no read side and there will not be one: a report is a message to the people who handle them, and letting the progress be watched (or letting anyone count how often an account has been reported) turns the queue into a weapon. The answer says it arrived, and nothing else. A person has one open report per thing: reporting the same profile or the same content again while the first is not closed answers 409 conflict, and the first one still stands. ARCADE_APP reports an Arcade game: it needs no username, since the account is the game's publisher, and it has uloggd check the game's URL again, at most once an hour per game.

Scope social.write · Counted against the write allowance

Body

FieldTypeNotes
onrequiredstringPROFILE, REVIEW, LIST, SCREENSHOT, DIARY, PROFILE_COMMENT, CONTENT_COMMENT or ARCADE_APP.
usernamestringThe account that published it. A report names the account it is about, even when it is about something that account published. Required for every kind but ARCADE_APP, where the database takes the account from the game itself.
reasonrequiredstringHARASSMENT, HATE_SPEECH, SPAM, IMPERSONATION, SEXUAL_CONTENT, CHILD_SAFETY, SELF_HARM, VIOLENCE, PRIVACY, SPOILER, SCAM or OTHER. Every one applies to any kind except SPOILER, which is for something posted (a review, session, list, screenshot or comment) and is refused with 400 on a PROFILE, and SCAM, which applies to ARCADE_APP only. CHILD_SAFETY, SELF_HARM and VIOLENCE go to the front of moderation's queue, and SCAM moves ahead too. OTHER names no rule, so it asks for details.
idstringThe content being reported. Required for anything but PROFILE, where the account itself is the subject. With ARCADE_APP, the game's app id.
detailsstringUp to 1000 characters. With OTHER it is required and at least 10 long, not counting spaces at either end: without that it answers 400.
instance_iduuidWith ARCADE_APP only, optional: the play the report came from. Moderation gets the release, the origin and the latest check of that moment with it.

Screenshots

The owner's captures.

Account

The account itself, and only with a session.