Content must be blocked when readable through the interface
When a content management system opens up its reading interface to the outside world, it is important to clarify the boundary between public and restricted content before discussing how to write the interface. The common practice is to divide by object type: the published text and column structure can be read, while account and permission data, un-published content, credentials and internal fields must be blocked, and write operations require authentication.
Which objects are covered by the endpoint
The WordPress API documentation puts it quite straightforward: REST endpoints represent articles, pages, taxonomies, and other built-in data types; generally, publicly available content on the site can be accessed publicly through the interface, while internal users, custom content types, and metadata are only accessible after authentication. There are two points that are easily overlooked in this description: first, the judgment of 'public' follows the visibility of the site itself, not all lists can be read; second, objects of the same type mixed with different visibility data, the interface cannot be released together just because the object type is the same.
The four types of data that must be blocked
| Data Category | Default visibility | Typical consequences after release | Sealing method |
|---|---|---|---|
| Published content and columns | Publicly readable | Within the expected range | Filtered by status, only formal content is displayed |
| Draft and content to be published | Must be blocked | Unfinished draft exposure in advance, preview link is crawled | Verify status when reading, preview is only given to authorized sessions |
| Background account, user group and permission data | Must be blocked | Role structure and leak of guessable usernames | Only appear in management interfaces after authentication |
| API key, access token and internal fields | Must be blocked | Leak of credentials leads to unauthorized write | Do not enter any external response, logs are desensitized as well |
Should the interface document write parameters or boundaries
It is not enough to list parameter names and example responses in the external document, but also need to specify which fields do not return, which states are unreadable, and which actions require authentication. AnQiCMS's interface capabilities are concentrated in high-frequency categories: document list and details, categories and tags, image upload, comments and replies, friendship links, system settings and contact information. When making API call connections, mark these six categories as 'readable/writeable', which is more effective in preventing accidental release than writing parameters one by one.
The location and purpose of the batch import interface
The most common batch scenario on the writing side is content import. AnQiCMS provides a document content import interface /api/import/archive, which supports querying whether a document exists by title, for batch import. The boundary points of this interface are three: the call requires valid credentials; the ownership of the target site for import must be explicitly specified; the result of checking for duplicates by title can only be used to decide whether to create a new one or skip, and cannot be used as a bypass for readable content.
When opening to the intelligent body, the tool surface needs to be collected again.
When the caller is an AI client rather than a human, the visible range should converge according to the ability directory. AnQiCMS is built-in MCP Server, the tool interface is based on the intention directory for unified convergence, write operations are accompanied by round-level operation approval, and can be accessed by external AI clients such as Claude, Cursor. Here, the judgment basis is not 'whether it can be called', but 'who to confirm before calling': the intention directory determines which actions the client can see, and the confirmation link determines whether the batch write will deviate once.
Common questions
Can the same endpoint return public content and draft?Can use the same endpoint, but the response must be filtered by status; the visibility is distinguished by the caller passing parameters, which is equivalent to handing over the boundary.
Can preview the link with one parameter to view a draft, is it a leak?It depends on whether the parameter is long-term valid and whether it can be crawled and indexed. The shareable preview should be bound to the validity period and authorization session to avoid becoming a long-term public address.
The interface document lists the field table, but what is missing?Lack of boundary description: which fields are never sent out, which states are not readable, and which actions require authentication and confirmation. These three things need to be written clearly separately.