Change log for the ITONICS REST API

Implication

Description

Category

Property removal and recalculation - user roles statistics endpoint

Change type / endpoint

Breaking:

• /api/user_stats/user_roles.json GET endpoint

Description of change

The default system roles anonymous user, authenticated user, administrator, and Service Account are no longer returned in the response, as they are not required for API reporting purposes. The distribution percentages of the remaining roles are recalculated accordingly and now sum to 100%.

Before (legacy response)

{ "anonymous user": { "total": "0", "distribution": "0.0 %" }, "authenticated user": { "total": "0", "distribution": "0.0 %" }, "administrator": { "total": "1", "distribution": "0.0 %" }, "Service Account": { "total": "1", "distribution": "0.0 %" }, "<role_name>": { "rid": "<role_id>", "total": "...", "distribution": "..." } }

After (new response)

{ "<role_name>": { "rid": "<role_id>", "total": "...", "distribution": "..." } }

Automations reading the four removed keys will receive a missing key. No error is returned, so failures will be silent.

Client action required

Remove any handling of the anonymous user, authenticated user, administrator, and Service Account keys from automations reading this endpoint. Re-check any logic, thresholds, or reporting based on the distribution values, as these have been recalculated across the remaining roles.

Implication

Description

Category

Validation enforcement - element POST/PUT endpoints

Change type / endpoint

Breaking:

• /api/{entity_type}.json POST
• and /api/{entity_type}/{id}.json PUT endpoints

Description of change

Three validation rules are now strictly enforced on requests that previously succeeded.

(1) Parent relation in draft status. Creating or updating a child element in draft status ("status": 0) without passing the parent relation previously succeeded. The parent_relation is now validated in draft status as well, and the request is rejected with a mandatory field validation error.

(2) Maximum number of users on multi-select User Search Fields. Passing more users than the maximum configured for the field previously succeeded and stored all values. The limit is now enforced:

422 Unprocessable Entity: Invalid value for {field:title}: exceeds maximum limit of {maximum:limit} users

(3) Single-value User Search Fields. Passing multiple usernames to a User Search Field that is not configured as multi-select previously succeeded and stored all values, while only one was displayed in the application. The request is now rejected:

422 Unprocessable Entity: {field:title}: Field only accepts a single value.

Client action required

(1) Include the parent_relation in POST and PUT requests that create or update child elements, including those in draft status. The required parent relation metadata can be retrieved via /api/entity_field_properties.json?type={entity_type}.

(2) Reduce the number of users passed to multi-select User Search Fields to the configured maximum.

(3) Pass a single username to User Search Fields that are not configured as multi-select.

Automations that do not write to child entity types or to User Search Fields are not affected.

Implication

Description

Category

Validation enforcement - date range filter parameters

Change type / endpoint

Breaking:

• /api/user.json GET endpoint, and /api/{entity_type}.json
• and /api/{entity_type}/{id}.json GET endpoints

Description of change

A logically invalid date range, where the from value is later than the to value (for example last_login_date_from later than last_login_date_to), previously returned a result set. The range is now validated and the request is rejected:

Invalid Date Range: to_date must be greater than from_date.

This previously produced inaccurate and misleading filtered results rather than an error.

Client action required

Review and correct any date filter where the from value is later than the to value, on both the user and the element GET endpoints. Requests that previously returned data will now return a validation error.

Implication

Description

Category

Validation message corrections, range widening, and count logic - various endpoints

Change type / endpoint

Non-breaking:

• /api/user.json GET endpoint; /api/{entity_type}.json
• and /api/{entity_type}/{id}.json GET, POST
• and PUT endpoints; /api/api_stats.json GET endpoint

Description of change

NUC-18065 - Date validation messages now name the parameter that was actually passed. An invalid date value previously returned 422 Unprocessable Entity: from_date: Invalid date. regardless of which parameter was used; it now returns, for example, 422 Unprocessable Entity: last_login_date_from: Invalid date. The status code and the outcome are unchanged.

NUC-18065 - For date picker fields with a configured date range, the accepted range was bound to the current month and day of the configured start and end years. It now spans the full year, from YYYY-01-01 to YYYY-12-31. This widens the accepted range: values previously rejected are now accepted, and nothing previously accepted is now rejected. The boundary values quoted in the validation message change accordingly.

NUC-17960 - number_of_shares in the element GET response previously reflected the number of permissions granted. It now returns the number of unique users with access to the element, counted once regardless of how many permissions they hold, and deduplicated across direct grants, user search fields, groups and contexts, and system roles. The count updates as role, group, and context membership changes, and decreases only when all of a user's access paths are removed. The field remains an integer.

NUC-18065 - /api/api_stats.json passing only from_date previously returned an empty list; it now returns results from that date onward. Passing only to_date previously returned HTTP 500 with an HTML error page; it now returns results up to that date.

Client action required

No immediate action required; existing automations continue to work without modification. Automations that match on the literal text from_date in date validation error bodies should be reviewed once. Where number_of_shares is used in reporting, note that the returned figure may differ from previous releases without any error being raised.

Category

Extended field-level filter coverage, rating and engagement filtering and sorting on the element GET endpoints, and rejection of unrecognised filter parameters

Change type / endpoint

Breaking:

• /api/{entity_type}.json and /api/{entity_type}/{id}.json GET endpoints (response structure and parameter validation)

Non-breaking:

• the submission and campaign GET endpoints

Description of change

Four changes affect the GET endpoints.

• Unrecognised filter parameters are rejected. A request containing a filter parameter that is not registered for the endpoint returns 412 Precondition Failed. Such parameters were previously ignored and the request was processed as if they had not been sent.
• The rating summary is returned on element GET responses. The rating_info object - the per-criterion summary of criteria name, average rating as decimal and string, count of rating users, and rating group - is part of the element response and can be omitted via the fields_excluded meta control. The individual rating records are retrieved via /api/entity_rating_info.json. That endpoint is unchanged, retains its existing filters and default ordering, and does not accept the new rating parameters.
• Rating and engagement filtering and sorting on element endpoints. New rating_criteria, rating_criteria_average_min, and rating_criteria_average_max parameters filter elements by their average rating for a given criteria, validated against the rating scale configured for that criteria. New sort values average_decimal, number_of_likes, and number_of_followers rank elements by rating value or engagement, combined with the existing direction parameter. sort=average_decimal requires rating_criteria. The /api/followers_likes.json endpoint is unchanged and does not apply sort parameters.
• Extended field-level filters. Filter parameters are available for number fields (exact value and _from / _to range), URL fields (partial match), email fields (full-address match, case-insensitive), single checkbox, radio button and pearl chain list renderers, segment and sub-segment fields, element search fields ({entity_id}-{entity_type}), user group search fields ({group_id}-group / {context_option_id}-context), and the default Description and Abstract fields (phrase search). Filtering on custom rich text and simple text fields is not supported. On the submission and campaign endpoints, filters are available for title, abstract, description, authors, campaign manager, and custom submission fields, together with five_star_min / five_star_max, criteria-based rating range filters (optionally scoped to a phase via rating_phase_id), and the sort values five_star and rating_criteria_average_decimal.

Client action required

• Review all GET requests for stray or misspelled parameters - any parameter not registered for the endpoint now fails the request with a 412 rather than being ignored. Automations that append optional or conditional parameters should be tested in a non-production (STAGE) environment before the upgrade.
• Review automations parsing element GET responses - the response includes a rating_info summary object. Parsers that iterate response keys, or that validate against a fixed schema, should be checked. Automations retrieving rating records from /api/entity_rating_info.json are not affected and require no change.
• No action required to keep existing filters working - all existing filter parameters, default ordering, and the permissions model are unchanged. The new filter and sort parameters are optional and can be adopted to replace client-side filtering and ranking.

Category

New lock property in the table configuration response

Change type / endpoint

Non-breaking:

• /api/entity_field_properties.json?type={entity_type}&config=table_data GET endpoint

Description of change

Introduced a Lock table for editing setting in the table configuration, which prevents users from adding, editing, or deleting rows in that table through the interface. The table configuration response now returns a locked property per table structure, true where the setting is enabled and false where it is not, so consuming systems can introspect the lock state. The property reflects a configuration change immediately.

The lock applies to the interface only. PUT requests to /api/table_data.json and Excel import write to locked tables exactly as they do to unlocked ones, and validation, error responses, and Excel export are unchanged. All pre-existing table structures are unlocked after the upgrade; the setting is opt-in and off by default.

Client action required

No action required; existing automations writing table data continue to work regardless of the lock state. Automations that read the table configuration can use the locked property to distinguish tables maintained by an integration from those maintained by users in the interface.

Category

New field selection meta controls for GET responses

Change type / endpoint

Non-breaking:

• /api/{entity_type}.json, /api/{entity_type}/{id}.json, /api/user.json, and /api/user/{id}.json GET endpoints

Description of change

Introduced two optional meta controls that narrow the GET response payload. fields_included returns only the listed field machine names plus the system-mandatory fields; fields_excluded returns the full payload without the listed fields. Both accept a comma-separated list of field machine names and combine with pagination, sorting, and all filter parameters.

The two controls are mutually exclusive - providing both in one request returns 400 Bad Request. An unrecognised machine name in either control returns 400 Bad Request. System-mandatory fields are always returned; listing one in fields_excluded retains it without raising an error.

Where neither control is provided, the full payload is returned. POST and PUT requests are unaffected.

Client action required

No action required; existing automations remain unaffected. The controls can be adopted to reduce payload size and response times - for example, retrieving user identity information without the base64-encoded profile image, or limiting element responses to the fields a reporting integration consumes. Field machine names can be retrieved via /api/entity_field_properties.json?type={entity_type} and /api/user_field_properties.json.

Category

Additional configuration properties in the submission field properties response, and validation enforcement on submission POST/PUT

Change type / endpoint

Non-breaking:

• /api/entity_field_properties.json?type=itonics_idea&camp_id={id} and &entity_id={id} GET endpoints
• /api/itonics_idea.json POST and /api/itonics_idea/{id}.json PUT endpoints

Description of change

Two changes affect the submission endpoints.

• Additional configuration properties. The field properties response now returns is_multiple for single line input, list and user search fields; the validator flags isNumber, isEmail and isUrl for single line input fields, of which at most one is present per field; and is_hybrid, limit_number and description for user search fields. The options object for list fields is keyed by option ID and maps to the option label. All previously returned properties are retained and the type values are unchanged - the field type renames introduced with this release apply to the configuration interface only.
• Validation against the field configuration. Submission POST and PUT requests now validate custom submission field values against the retrieved configuration, returning 422 Unprocessable Entity identifying the field where a value does not match. This covers arrays passed to single-value fields, option IDs not configured on a list or radio button field, values failing a configured number, email or URL validator, and user search fields exceeding the configured maximum number of users. Validators are applied per entry on multi-value fields, and nothing is stored where any entry is rejected.

Client action required

No action required for automations passing values that already match the campaign's field configuration. Automations writing to custom submission fields should be reviewed once in a non-production (STAGE) environment, as values that were previously accepted and stored without matching the configuration are now rejected - in particular option labels passed in place of option IDs, arrays passed to single-value fields, and user search fields exceeding the configured maximum. Retrieve the current configuration via /api/entity_field_properties.json?type=itonics_idea&camp_id={id}.

Implication

Description

Category

New GET endpoint for the roadmap configuration change log

Change type / endpoint

Non-breaking:

• New /api/roadmap_logs/roadmap-configuration.json GET endpoint

Description of change

Introduced a new endpoint returning the roadmap configuration change log: every create, edit, delete, archive, and restore action on a roadmap, with one record per save event. Each record carries the roadmap, the action, the acting user as a username, the timestamp, and a change_summary grouped into general properties, default color and label configuration, and layers. The change_summary is null for created, deleted, archived, and restored records.

The endpoint supports the from_date and to_date filter controls (YYYY-MM-DD or YYYY-MM-DD hh:mm:ss), an action filter, a roadmap_id filter returning the log of a single roadmap, and page and limit pagination. Access is controlled via the new "Access roadmap configuration log via api" permission (global permission).

Events are logged from the activation of the feature onward; earlier roadmap changes are not back-filled.

Client action required

No action required; existing automations remain unaffected. To utilize the endpoint, grant the new permission to the utilized API users. The log supports audit and governance reporting on roadmap configuration changes, including changes to the Roadmap Manager assignment.

Implication

Description

Category

Pagination ordering, share count alignment, and last editor attribution - various endpoints

Change type / endpoint

Non-breaking:

• /api/entity_rating_info.json and /api/followers_likes.json GET endpoints
• /api/{entity_type}.json and /api/{entity_type}/{id}.json GET endpoints
• /api/itonics_idea.json and /api/itonics_idea/{id}.json GET endpoints

Description of change

• The rating data and followers and likes endpoints now apply an explicit order by record ID before pagination. These queries previously applied a limit without an order, so records could be skipped or repeated across pages when the underlying data changed between requests. Paging now returns each record exactly once. The result order differs from previous releases: the rating data endpoint returns records oldest first by record ID rather than by rating date. The rating_from_date, rating_to_date, and rating_status filter controls are unchanged.
• number_of_shares in the element list response now excludes archived shares, matching the single-element response.
• The last editor of an element is now updated for update actions performed from the element details page, including adding tags, adding relations, assigning users to a user search field, archiving, and workflow actions. Previously the value was updated only when the element was saved from the edit form, so an element created via API and subsequently modified from the details page retained its original editor. The same applies to campaigns and submissions. The property is unchanged in name and format.

Client action required

No immediate action required; existing automations continue to work without modification. Automations that page through the rating data endpoint and rely on records arriving newest first should be reviewed once, as the order has changed — where a period is required, use the rating_from_date and rating_to_date filter controls rather than relying on the result order. Where number_of_shares or the last editor value is used in reporting, note that the returned figure may differ from previous releases without any error being raised.

Implication

Description

Category

Support of the OAuth 2.0 Client Credentials Grant flow, and a new Credential Management interface

Change type / endpoint

Non-breaking:

• OAuth 2.0 authentication (new grant type)
• All API endpoints (identity and attribution of requests authenticated with a client credentials token)

Description of change

Introduced support for the OAuth 2.0 Client Credentials Grant flow for machine-to-machine integrations that act on their own behalf rather than on behalf of a user. The automation authenticates against the POST /oauth2/token endpoint with grant_type=client_credentials, a Client ID, and a Client Secret; no username or password is transmitted.

Permissions are resolved from the roles bound to the credential. No element-level permissions (visibility tab, user and user group search fields, granted permissions) are evaluated, as no user account is bound - regardless of whether the RBAC-enforced API mode is active. Write operations are attributed to the global API Automation persona (created_by on POST, last_editor on PUT), and the client_id is recorded in the audit log on every request.

Credentials are maintained in the new Credential Management interface under System Administration → API Management, where they can be edited, rotated, disabled, and revoked. Credential changes are recorded under Audit Logs; client secrets are never stored.

Client action required

No action required; existing OAuth 2.0 clients and authentication flows (password, refresh token, and authorization code grant types) remain unchanged. To utilize the client credentials grant type, the feature must be activated by ITONICS - please contact your Customer Success Manager.
Note that element-level permissions are not evaluated for these tokens - refer to the client credentials grant type section for the full permission model.

Category

Externalization of rating, follower, and like data into new dedicated GET endpoints, and addition of new rating filter parameters

Change type / endpoint

Breaking:

• api/{entity_type}.json and /api/{entity_type}/{id}.json GET endpoints
• New:
• /api/entity_rating_info.json?entity_type={entity_type},
• /api/entity_rating_info.json?entity_type={entity_type}&entity_id={id},
• /api/followers_likes.json?entity_type={entity_type}, and
• /api/followers_likes.json?entity_type={entity_type}&entity_id={id} GET endpoints

Description of change

• Removed the detailed rating information (rating_info / rating_data) and the detailed follower and like lists (followers / liked_by) from the element GET responses to improve endpoint performance; only the summary counts remain in the element response.
• Introduced new dedicated GET endpoints to retrieve the detailed rating data (rating summary per criterion and individual rating records, sorted latest first, supporting the new rating_from_date, rating_to_date, and rating_status filter parameters) and the detailed follower and like user lists, both supporting page and limit pagination.
• Access is controlled via the new "Access the resource rating of <entity type> via API" and "Access the resource followers_likes via API" permissions.

Client action required

Existing automations reading rating_info, rating_data, followers, or liked_by from the element GET endpoints must be updated to retrieve this data via the new /api/entity_rating_info.json and /api/followers_likes.json endpoints. Ensure the utilized API users are granted the respective new API resource permissions. Automations relying only on element field data or summary counts are not affected.

Category

New roadmap PUT endpoint, new roadmap configuration GET endpoint, and connection type data in the roadmap GET response

Change type / endpoint

Non-breaking:

• New /api/roadmap/{id}.json PUT endpoint and /api/roadmap_field_properties/{id}.json
• GET endpoint; enriched /api/roadmap/{id}.json?type=connection GET endpoint

Description of change

• Introduced a new PUT endpoint to update an existing roadmap: adding existing elements to roadmap layers, updating element placement dates (incl. synced vs. custom date handling via the date_mode property), and creating, updating, and deleting milestones and connections (incl. connection types).
• Introduced a new GET endpoint /api/roadmap_field_properties/{id}.json returning the layer hierarchy with valid layer IDs and the connection types enabled for the particular roadmap.
• The /api/roadmap/{id}.json?type=connection GET response now additionally includes a connection_type_info object per connection (id, title, color, line style, and sync flag).
• Access to the PUT endpoint is controlled via the new "Use roadmap PUT API" permission in combination with edit access to the particular roadmap. Creating new roadmaps (POST) remains unsupported.

Client action required

No action required for existing automations. To utilize the new endpoints, grant the respective permissions to the utilized API users and refer to the public Postman API collection for the request body specifications.

Category

Introduction of an optional RBAC-enforced API authorization mode

Change type / endpoint

Non-breaking:

• All API endpoints (authorization behavior; opt-in)

Description of change

• Introduced an optional, opt-in API authorization mode that evaluates application-level permissions in addition to the API permissions for all API requests, ensuring API access can never exceed a user's access within the application (strict RBAC parity between application and API).
• The default (legacy) authorization behavior remains unchanged and stays active unless the mode is explicitly enabled.

Client action required

No action required; existing integrations remain unaffected by default. If strict permission parity is required (e.g., for integrations retrieving data on behalf of individual users), the RBAC-enforced mode can be activated by ITONICS upon request via your Customer Success Manager. Before activation, review the application-level permissions of all utilized API users and test existing integrations in a non-production (STAGE) environment.

Category

Support of the OAuth 2.0 Authorization Code Grant flow (incl. PKCE and user consent)

Change type / endpoint

Non-breaking:

• OAuth 2.0 authentication (new, isolated authorization server configuration)

Description of change

• Introduced support for the OAuth 2.0 Authorization Code Grant flow: the client application redirects the user to the authorization endpoint, the user authenticates and explicitly grants consent, and the resulting single-use, expiring authorization code is exchanged for an access token at the token endpoint.
• The flow supports PKCE, and redirect URI and scope validation are enforced.
• The new authorization server configuration is isolated from the existing OAuth 2.0 implementation.

Client action required

No action required; existing OAuth 2.0 clients and authentication flows (password and refresh token grant types) remain unchanged. To utilize the Authorization Code Grant flow for a new integration (e.g., user-consent-based third-party applications), a dedicated OAuth2 client (redirect URIs and allowed scopes) must be configured by ITONICS — please contact your Customer Success Manager.

Implication

Description

Category

Response format alignment, data type correction, and property removal — field properties endpoints

Change type / endpoint

Breaking:

• /api/entity_field_properties.json?type={entity_type},
• /api/entity_field_properties.json?type=itonics_campaign_tr3,
• /api/entity_field_properties.json?type=itonics_idea&camp_id={id},
• /api/entity_field_properties.json?type={entity_type}&config=milestone,
• and /api/user_field_properties.json GET endpoints

Description of change

Four changes affect the field properties endpoints.

(1) Pagination has been removed — the response is no longer wrapped in a pagination object; field properties are returned directly in the response body. Automations that unwrap a pagination envelope or iterate across pages will receive no data.

(2) The is_multiple property for searchable dropdown list fields now returns a boolean (true/false) instead of an integer (1/0). No error is returned on mismatch, so failures will be silent.

(3) The type value within the relations object for relation fields has changed from "numeric" to "autosuggest_search_field", and a "description" property has been added; conditions matching type == "numeric" no longer match.

(4) The following properties have been removed: limit_number for element search fields (entity and campaign configuration) and for user search fields (milestone configuration); required for the external gateway fields firstname, lastname, and email, replaced with a description (these fields are read-only via the API); Roadmap and Submission from the relations object for campaign configuration; and Roadmap from relations for submission configuration.

Client action required

(1) Read field properties directly from the response body — remove any logic that unwraps a pagination object or iterates across pages.

(2) Update comparisons on is_multiple from integer (1/0) to boolean (true/false).

(3) Update conditions matching relation field type from "numeric" to "autosuggest_search_field".

(4) Remove any references to limit_number; to required on the external gateway fields firstname, lastname, and email; and to Roadmap and Submission in relations where they are no longer returned.

Implication

Description

Category

Response format correction — element GET endpoints

Change type / endpoint

Breaking:

• /api/{entity_type}.json and
• /api/{entity_type}/{id}.json GET endpoints

Description of change

Where rating criteria contain inactive ratings, the users property was previously returned as an object; it is now always returned as an array. A range_name key has additionally been added to the rating_data object.

Client action required

Update automations that read users from rating data to always expect an array, regardless of whether ratings are active or inactive.

Implication

Description

Category

Validation enforcement — element POST/PUT endpoints

Change type / endpoint

Breaking:

• /api/{entity_type}.json POST, and
• /api/{entity_type}/{id}.json PUT endpoints

Description of change

Two validation rules are now strictly enforced.

(1) Mandatory file upload fields — if a Single File Upload or Multiple File Upload field is configured as mandatory on an entity type, requests that omit it now return a validation error; these requests previously succeeded silently.

(2) is_archived is now supported in PUT only; POST requests that include is_archived return a validation message. Draft elements cannot be archived.

Client action required

(1) Review POST and PUT requests against entity types with mandatory file upload fields and ensure the relevant field is populated.

(2) Remove is_archived from POST requests and apply it only via PUT. Do not send is_archived on draft elements.

Implication

Description

Category

HTTP status code correction — table data PUT endpoint

Change type / endpoint

Breaking:

• /api/table_data.json?entity_type={entity_type}&entity_id={id} PUT endpoint

Description of change

On validation failure, the endpoint now returns the appropriate 4XX HTTP status code. Previously, a 200 OK was returned with the error detail embedded in the response body.

Client action required

Review automations that branch on the HTTP status code for this endpoint — responses that previously appeared successful will now surface as errors and must be handled accordingly.

Implication

Description

Category

HTTP method enforcement and error response format — all endpoints

Change type / endpoint

Breaking:

• Breaking: all API endpoints

Description of change

Two general changes apply across all endpoints.

(1) Unsupported HTTP methods — DELETE, PATCH, HEAD, and OPTIONS now return 405 Method Not Allowed with a validation message. These methods previously returned a success response, although no action was ever taken.

(2) Invalid entity type — passing an invalid entity type previously returned an HTML page with a 404 status; a JSON validation message is now returned instead.

Client action required

(1) Review any automations that call DELETE, PATCH, HEAD, or OPTIONS against any endpoint — these will now receive a 405 error.

(2) Update error-handling logic that reads the response body for an invalid entity type to expect JSON rather than HTML.

Implication

Description

Category

Response enrichment and corrections — various endpoints

Change type / endpoint

Non-breaking:

• /api/entity_field_properties.json,
• api/user_field_properties.json,
• /api/user.json GET endpoints;
• POST on /api/itonics_idea.json

Description of change

• parent_relation is now included in the entity field properties response for child entity types, with required, type, and entity_type metadata.
• user_groups and user_background are now returned by /api/user.json, and Banner Image is included in the user field properties response — closing a gap where API-based re-imports could unassign user groups or drop banner images.
• is_multiple is now present in entity field properties for tags, term search, and single and multiple file upload fields, where it was previously absent. is_multiple is corrected to true for interest, term search, and multiple file upload fields in /api/user_field_properties.json — these fields always accepted multiple values; only the metadata was incorrect.
• POST Submission now accepts a single campaign ID under relations in both campaign_id and [campaign_id] form, instead of returning a 500.

Client action required

No immediate action required. Existing automations remain unaffected. These additions and corrections can be leveraged to improve the completeness and accuracy of reporting and data-import automations.

Implication

Description

Category

Improved search performance and matching behaviour for the query full-text filter parameter

Change type / endpoint

Non-breaking:

• All GET endpoints using the query filter parameter, in particular
  • /api/{entity_type}.json?query={search_term}, and
  • /api/itonics_idea.json?query={search_term}

Description of change

Client action required

No immediate action required; existing automations continue to work without modification. Automations relying on the query filter parameter should be reviewed once, as the set of returned elements and their order may differ from previous releases — in particular where a search term matches a fragment from the middle of a word. Where an exact set of elements is required, we recommend using the dedicated field filter parameters (for example title, tag, or a field machine name filter) rather than the query full-text filter.

Non-breaking:

• /api/timeline.json?entity_type={entity_type}, and
• /api/timeline.json?entity_type={entity_type}&entity_id={entity_id} GET endpoints

• Introduced new (optional) timeline_from_date and timeline_to_date filter parameters to narrow down timeline data more granular for a specific time period
• Added a new changed_at property indicating hh:mm:ss to the GET response, allowing to retrieve the full ISO timestamp in combination with the existing YYYY-MM-DD information (which timeline records are grouped by)