An article is long-form writing. It is a content item, so it has an owner, a body, media, tags, categories and the full engagement set — and it is the one item designed to be filed under something else.
Where an article can live
An article may name a parent, and that decides where it appears:
| Parent | Article appears at |
|---|---|
| Nothing | /articles — the site-wide article browser |
| An app | The app’s article section |
| A community | /c/<community>/articles |
| A mod | The mod’s Articles tab |
| A server | The server’s Articles tab |
| An asset | The asset’s Articles tab |
| A user | The member’s own article section on their profile |
An article always also appears in the global browser, filed under whatever category it carries.
Fields
- titlestringrequired
The headline. Note this is
title, notname— articles are the one item type that spells it that way, on both the model and the API.- contentmarkdownrequired
The body.
- descriptionstring
The standfirst — what shows on cards and in search results.
- isOfficialboolean
Marks a first-party post. Staff-only, and rejected by the API for everybody else.
The blog
/blog is the site’s own article feed: the subset of articles published by the
team. It is the same model, filtered.
What can be attached
Media, contributors, permissions, tags and categories, and the full engagement and follow set.
Articles take no releases, no links and no dependencies.
Through the API
/api/content/articleAPI keycanWritetitle and content are required. Every parent is optional and at most one is
meaningful: appId, communityId, modId, serverId, assetId,
userTargetId.