InfoboardPosts
Introduction
InfoboardPosts are the primary Infoboard content resource. A post can belong to an InfoboardChannel, target Users or Departments, accept InfoboardComments, and require explicit reading confirmation.
Post visibility combines Targetables with inherited channel Entity Permissions when a channel is assigned.
The text field uses the shared Rich Text HTML format.
Model Definition
Alias
infoboardPost
Relations
Assignment modes
null- Do not target users or departments. This is unavailable when the assigned channel hasapply_allowed_departmentsenabled.any_of- Target the explicitly assigned departments. Direct user assignment is currently ignored by the create and update endpoints.
Comment visibility constraint types
department- Limit comments to the author's department.private- Limit comments to users with the applicable private-comment access and allowed department context.null- Do not impose a comment visibility constraint.
Computed Properties
hash- Hashed representation of the postid.
Capabilities
Targetables -
assign_modeanddepartmentsdefine direct post visibility; onlynullandany_ofare supported, and direct user targets are currently removed from requests.Entity Permissions - Posts inherit the
viewand administration effects of their assigned channel and do not own independent Entity Permissions.URL Context - Post URLs resolve to access-checked context information.
Translations - The
titleandtextfields are translatable.Notifications - Publishing and relevant updates can notify eligible targeted users when the parent channel enables notifications.
Reactions - Posts accept reactions when
reactions_forbiddenisfalse.Seen and Read Tracking - Seen records track visible posts, read records capture explicit confirmations, and
reading_confirmationtells clients whether a confirmation is required.
User Can Create Posts
Check whether the authenticated user can create at least one InfoboardPost globally or in an accessible channel.
Definition
GET /api/infoboard/user-can-create-posts
Behavior
The result accounts for both the global post-creation permission and channel-specific creation grants.
Example Request
Example Response
Unseen and Unread Statistics
List unseen and unread post counts grouped by channel for the authenticated user.
Definition
GET /api/infoboard/unseen-unread-posts-statistics
Behavior
Shared value filters can narrow the posts before counts are calculated.
Only posts the user may mark as seen or read are counted.
infoboard_channel_idisnullfor posts outside a channel.
Example Request
Example Response
List
List InfoboardPosts visible to the current authenticated user.
Definition
GET /api/infoboard/posts
Behavior
Visibility includes owned posts and posts available through Targetables, inherited channel Entity Permissions, or an explicit entity grant.
Scheduled posts remain hidden until their publication time unless the applicable ownership or scheduling access permits them.
Example Request
Example Response
Count
Count InfoboardPosts visible to the current authenticated user.
Definition
GET /api/infoboard/posts/count
Behavior
The same visibility, publication, and shared filter rules as the list endpoint apply.
Example Request
Example Response
Show
Show one visible InfoboardPost by ID or hash.
Definition
GET /api/infoboard/posts/{infoboardPost}
Route Parameters
infoboardPost
integer | string
InfoboardPost ID or hash.
Behavior
The same Targetables, inherited Entity Permissions, grants, ownership, and publication rules as the list endpoint apply.
Example Request
Example Response
Create
Create a new InfoboardPost.
Definition
POST /api/infoboard/posts
Request Keys
lang_id
string
system language
Language key for the translatable content.
title*
string
-
Post title.
text*
string
-
Post content, which can contain HTML.
reading_confirmation
boolean
false
Whether users must explicitly confirm reading.
comments_allowed
boolean
true
Whether comments can be created.
comment_user_confirmation_required
boolean
false
Whether comment creation requires a confirmed non-group user identity.
force_comment_visibility_constraint
boolean
false
Whether comments must use the post's configured constraint.
pinned
boolean
false
Whether the post is pinned.
pinned_end
datetime | null
null
Future date at which pinning ends. Relative dates are accepted.
planned_publish_at
datetime | null
null
Future publication date. Relative dates are accepted.
delete_interval
string | null
null
ISO 8601 date interval after which the post can be deleted automatically.
department_ids
array
[]
IDs of departments targeted by the post.
Keys with * are required.
Behavior
The authenticated user becomes the owner; client-provided
user_idanduser_idsvalues are ignored.Supplying departments defaults
assign_modetoany_of; otherwise it defaults tonull. A channel withapply_allowed_departmentsenabled requires at least one department and removes department IDs the author may not assign.Without a future
planned_publish_atand scheduling permission, the post is published immediately. A valid future value storespublished_atasnulluntil publication. Client-providedpublished_atis normalized by this rule.pinnedandpinned_endapply only with pin permission. Otherwisepinnedbecomesfalseandpinned_endbecomesnull.delete_intervalapplies only when the user may delete the post; otherwise it becomesnull.Creating a published post can trigger notifications for eligible targeted users.
Example Request
Example Response
Reset Relations
Reset selected dependent relations of an InfoboardPost.
Definition
POST /api/infoboard/posts/{infoboardPost}/reset
Route Parameters
infoboardPost
integer | string
InfoboardPost ID or hash.
Request Keys
seenUsers
boolean
false
Delete seen-user records when true.
readUsers
boolean
false
Delete read-user records when true.
comments
boolean
false
Delete comments when true.
reactions
boolean
false
Delete reactions when true.
targetedSurveyVotes
boolean
false
Delete votes from surveys targeting the post when true.
Behavior
At least one resettable relation must be set to
true; otherwise the operation returns an error response.Relation-specific delete behavior runs for each selected relation, including comment notification cleanup.
Example Request
Example Response
Update
Update an existing InfoboardPost.
Definition
PUT /api/infoboard/posts/{infoboardPost}
Route Parameters
infoboardPost
integer | string
InfoboardPost ID or hash.
Request Keys
lang_id
string
Language key for the translatable content.
title
string
Post title.
text
string
Post content, which can contain HTML.
reading_confirmation
boolean
Whether users must explicitly confirm reading.
comments_allowed
boolean
Whether comments can be created.
comment_user_confirmation_required
boolean
Whether comment creation requires a confirmed non-group user identity.
force_comment_visibility_constraint
boolean
Whether comments must use the post's configured constraint.
pinned
boolean
Whether the post is pinned.
pinned_end
datetime | null
Future date at which pinning ends. Relative dates are accepted.
planned_publish_at
datetime | null
Future publication date. Relative dates are accepted.
delete_interval
string | null
ISO 8601 date interval after which the post can be deleted automatically.
department_ids
array | null
IDs of departments targeted by the post.
Behavior
A client-provided
user_idoruser_idsvalue is ignored. Changinginfoboard_channel_id,title, ortextmakes the authenticated user the owner.Changing
titleortextremoves stored translations for the changed source fields.Changing the channel without
department_idsclears department targets. Any channel change also resets seen users, read users, comments, reactions, and targeted survey votes before new departments are synchronized.Department assignment follows the same
nullorany_ofrules and allowed-department filtering as creation.Changing
planned_publish_atto a valid future value schedules the post and clearspublished_at; changing it tonull, now, or the past publishes immediately. A published post cannot be republished before its existingpublished_atvalue.Pin fields are ignored without pin permission, and
delete_intervalis ignored without delete permission.Relevant content, publication, and Targetable changes can trigger updated-post notifications.
Example Request
Example Response
Delete
Delete an existing InfoboardPost.
Definition
DELETE /api/infoboard/posts/{infoboardPost}
Route Parameters
infoboardPost
integer | string
InfoboardPost ID or hash.
Behavior
The post is soft-deleted.
Notifications targeting the post are deleted, and every related comment runs its normal deletion lifecycle.
Example Request
Example Response
Last updated