For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Logo
DeveloperAcademyCommunityStatus
    • Overview
    • API Credentials
    • Errors
    • Legacy & Deprecated APIs
  • Events API
    • Chat Markup
    • Rate Limits
    • Message Delivery
  • (Beta) Conversations API
  • Data API
    • GETList conversations
    • GETList interactions
    • GETList plugins calls
    • GETList Plugin Resources
    • GETList Users
  • Webhook Listeners
  • Content Gateway
    • Overview
    • Integration Strategies
    • Starter Code
    • Verifying Your Build
    • Connecting Your Gateway to Moveworks
    • Authentication
    • How Permissions Work
    • Common Pitfalls
    • Operational Guide
    • Errors
    • Supported MIME Types
  • Legacy Gateways
    • Authentication
    • Response Options
      • GETList Articles
    • Field Types
    • Form Gateway Errors
DeveloperAcademyCommunityStatus
Legacy GatewaysKnowledge Gateway

List Articles

||View as Markdown|
GET
http://localhost:5000/myinstance1/articles
GET
/myinstance1/articles
$curl -G http://localhost:5000/myinstance1/articles \
> -H "Authorization: Bearer <token>" \
> --data-urlencode "filter=article.state eq "ACTIVE"
>"
200Retrieved
1{
2 "results": [
3 {
4 "id": "12334",
5 "title": "How to get zoom access",
6 "body": "<html></html>",
7 "link": "https://www.article1.com",
8 "created_at": "2023-05-14T09:30:00Z",
9 "updated_at": "2023-05-14T09:30:00Z",
10 "created_by": "abc@moveworks.ai",
11 "updated_by": "abc@moveworks.ai"
12 }
13 ],
14 "next_page_token": "ABCD1234"
15}

Description:
The endpoint should return a list of articles in deterministic order.
We recommend a rate limit of 10 req/sec for this endpoint.



Usage:

Moveworks will call this endpoint to ingest articles every 4 hours.
Ask your CSE if you wish to increase or decrease the polling frequency.

Was this page helpful?
Previous

List Forms

Next
Built with

Authentication

AuthorizationBearer

Bearer authentication of the form Bearer <token>, where token is your auth token.

Query parameters

pageTokenstringOptional

pageToken is used to paginate query results.
If pageToken is not used in a request, the response should default to the first page.

The response should always include a next_page_token field.
To obtain the next page of results, the client will use next_page_token as the value of pageToken in the next request.

When combining the filter parameter with the pageToken parameter, servers must ensure that the client uses the appropriate pageToken value for the specified filter string. Failure to do so should result in the server throwing an “INPUT_VALIDATION_FAILED”.

pageSizelongOptional

pageSize defines the maximum number of articles to return in a single query.

Moveworks will take a max of 1000 articles in a single response. However, the server can return less than 1000 if desired.

filterstringOptional
Defines a filter expression that narrows down the returned set of items. It allows you to specify criteria, such as numeric comparisons or string matching, to filter the items based on the values of their properties. The filter parameter must include at least one valid Boolean expression. Each expression should consist of an attribute name, followed by an attribute operator and a value. You have the flexibility to combine multiple expressions using logical operators, and you can also group expressions together using parentheses “()”. Here are the available attribute operators and their descriptions: - **`eq`** (equal): The attribute and operator values must be identical for a match. - **`ne`** (not equal): The attribute and operator values are not identical. - **`gt`** (greater than): If the attribute value is greater than the operator value, there is a match. The actual comparison depends on the attribute type. - **`lt`** (less than): If the attribute value is less than the operator value, there is a match. The actual comparison depends on the attribute type. The boolean operators available for combining expressions are: - **`and`** (Logical AND): The filter is considered a match only if both expressions evaluate to true. - **`or`** (Logical OR): The filter is considered a match if either of the expressions evaluates to true. Parentheses **`()`** can be used to group boolean expressions and alter the standard order of operations. By grouping expressions with parentheses, you can control how the logical OR operation is evaluated and prioritize certain conditions over others. This allows for more flexibility and precision in constructing complex boolean expressions. Attribute names and attribute operators used in filters are case insensitive. For example, the following two expressions will evaluate to the same logical value: filter=article.state Eq "ACTIVE" filter=article.State eq "ACTIVE" The evaluation of filters follows a standard order of operations. Attribute operators take precedence over other operators, followed by the grouping operator (parentheses), then the logical AND operator, and finally the logical OR operator. If the requested filter operation is not recognised, providers must refuse to filter the results and return an HTTP 400 error with an appropriate human readable response. **Here are some examples of filter expressions:** In the provided examples, we have utilised the suggested response structure as defined in the response section. However, it's important to note that these expressions may differ if you opt for an alternative response format or structure. - filter=last_modified_at gt "2011-05-13T04:42:34Z" - filter=article.state ne “INACTIVE” and last_modified_at gt "2011-05-13T04:42:34Z"

Response headers

X-RateLimit-Limitinteger
The maximum number of requests you're permitted to make per minute.
X-RateLimit-Remaininginteger
The number of requests remaining in the current rate limit window.
X-RateLimit-Resetstring
The remaining window before the rate limit FULLY resets in UTC epoch seconds.

Response

List of articles
resultslist of objects
next_page_tokenstring
The value provided serves as the starting point for fetching the next page of records. In the next call, use this value as the pageToken parameter.

Defines a filter expression that narrows down the returned set of items. It allows you to specify criteria, such as numeric comparisons or string matching, to filter the items based on the values of their properties.

The filter parameter must include at least one valid Boolean expression. Each expression should consist of an attribute name, followed by an attribute operator and a value. You have the flexibility to combine multiple expressions using logical operators, and you can also group expressions together using parentheses “()”.

Here are the available attribute operators and their descriptions:

  • eq (equal): The attribute and operator values must be identical for a match.
  • ne (not equal): The attribute and operator values are not identical.
  • gt (greater than): If the attribute value is greater than the operator value, there is a match. The actual comparison depends on the attribute type.
  • lt (less than): If the attribute value is less than the operator value, there is a match. The actual comparison depends on the attribute type.

The boolean operators available for combining expressions are:

  • and (Logical AND): The filter is considered a match only if both expressions evaluate to true.
  • or (Logical OR): The filter is considered a match if either of the expressions evaluates to true.

Parentheses () can be used to group boolean expressions and alter the standard order of operations. By grouping expressions with parentheses, you can control how the logical OR operation is evaluated and prioritize certain conditions over others. This allows for more flexibility and precision in constructing complex boolean expressions.

Attribute names and attribute operators used in filters are case insensitive. For example, the following two expressions will evaluate to the same logical value: filter=article.state Eq “ACTIVE” filter=article.State eq “ACTIVE”

The evaluation of filters follows a standard order of operations. Attribute operators take precedence over other operators, followed by the grouping operator (parentheses), then the logical AND operator, and finally the logical OR operator.

If the requested filter operation is not recognised, providers must refuse to filter the results and return an HTTP 400 error with an appropriate human readable response.

Here are some examples of filter expressions: In the provided examples, we have utilised the suggested response structure as defined in the response section. However, it’s important to note that these expressions may differ if you opt for an alternative response format or structure.

  • filter=last_modified_at gt “2011-05-13T04:42:34Z”
  • filter=article.state ne “INACTIVE” and last_modified_at gt “2011-05-13T04:42:34Z”