Change log for the ITONICS REST API

This section is dedicated to tracking all modifications, enhancements, and deprecations related to the ITONICS Enterprise REST API . Its primary purpose is to provide a clear, chronological reference regarding breaking and noteworthy changes that could potentially affect existing automations or integrations.

We document all changes, clearly distinguishing between Breaking changes (which require client action) and Non-Breaking changes (which provide further information or context).

Please note: This feature needs to be activated by ITONICS. Please contact your Customer Success Manager or Account Manager for further assistance.

Table of contents

3.25.0 major release
3.24.5 minor release
3.24.4 minor release
3.24.3 minor release
3.24.0 major release
3.23.0 major release
3.22.0 major release
3.21.0 major release
3.20.0 major release
3.19.0 major release

Structure

The change log is presented in reverse chronological order (latest changes at the top) and uses the following column structure to define the impact of each update:

Implication	Description
Category	The area of the API affected (e.g., data structure, endpoint, authentication, input format, meta control).
Change type / endpoint	Breaking: Requires immediate client action to prevent integration failure. Non-Breaking: An optional enhancement or internal change that does not break existing automations.
Description of change	A concise technical explanation of the modification made.
Client action required	Specific, clear instructions on what the client must do to maintain functionality or utilize the new feature.

Change log

3.25.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.25.0 major release. Refer to the release notes for more detailed information on the release.

(1) NUC-16638

Implication	Description
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.

(2) NUC-17972

Implication	Description
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.

(3) NUC-17207

Implication	Description
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.

(4) NUC-19181

Implication	Description
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.

3.24.5 minor release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.24.5 minor release. Note that the same changes are also included in the 3.25.3 minor release. Refer to the release notes for more detailed information on the release.

(1) NUC-14802

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.

(2) NUC-18868, NUC-13941, and NUC-15303

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.

(3) NUC-18065

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.

Additional changes - no action required

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.

3.24.4 minor release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.24.4 minor release. Note that the same changes are also included in the 3.25.2 minor release. Refer to the release notes for more detailed information on the release.

(1) NUC-18722

Implication	Description
Category	Input format update for Element Search Field (ESF) columns in table structures, and validation enforcement.
Change type / endpoint	Breaking: /api/table_data.json?entity_type={entity_type}&entity_id={id} PUT endpoint
Description of change	Aligned the input format for Element Search Field (ESF) columns in table structures with the standard element mapping format used across the rest of the ITONICS API. Previously, element relations within an ESF table column were mapped using plain-text element titles (or comma-separated titles for multiple elements). Where elements with identical titles existed across several entity types, all matching elements were mapped, which could produce unintended relations. Before (legacy payload) { "<table_machine_name>": { "rows": { "<option_key>": { "column_data": { "<option_key>": "Element Title" } } } } } After (new payload) { "<table_machine_name>": { "rows": { "<option_key>": { "column_data": { "<option_key>": { "<entity_type_machine_name>": [1, 2, 3], "<entity_type_machine_name>": 1 } } } } } } Element relations must now be expressed as an object keyed by entity type machine name, with explicit element IDs as values. A single element ID can be passed as an integer; multiple element IDs for the same entity type must be passed as an array of integers. Validation is now strictly enforced: an invalid entity type machine name, an element title passed in place of an element ID, or a non-existent element ID returns a validation error. The request only passes if all entity types and element IDs in the payload are valid. Requests using the legacy title-based format previously returned a 200 OK without persisting the relation.
Client action required	Update existing automations writing to ESF columns in table structures as follows: (1) Replace any element title strings in column_data values with the corresponding element IDs (integers). (2) Group element IDs by their entity type machine name using the nested object structure. (3) Use an array of integers when mapping multiple elements for a single entity type; a single integer is accepted for one element. Entity type machine names and table structure configuration can be retrieved via /api/entity_field_properties.json?type={entity_type}&config=table_data. Element IDs can be retrieved via the respective element GET endpoints. Automations that do not write to ESF columns in table structures are not affected.

(2) NUC-19752

Implication	Description
Category	Response format correction for Element Search Field (ESF) values in timeline data, and completeness of logged ESF relation events
Change type / endpoint	Breaking: `/api/timeline.json?entity_type={entity_type}`, and `/api/timeline.json?entity_type={entity_type}&entity_id={entity_id}` GET endpoints
Description of change	Two changes affect the timeline endpoints. (1) Response format. Element Search Field (ESF) values within the `old_value` and `new_value` objects are returned as an array of element objects per entity type machine name. Previously, a single element object was returned per entity type, so only one element was represented in the timeline record even where several elements were mapped to the field — the remaining relations were silently omitted from the response. Before (legacy payload) <pre>"new_value": { "field_label": "<field_label>", "field_value": { "<entity_type_machine_name>": { "field_value": { "id": "14", "title": "Element Title", "entity type": "<entity_type_machine_name>" } } } }</pre> After (new payload) <pre>"new_value": { "field_label": "<field_label>", "field_value": { "<entity_type_machine_name>": [ { "field_value": { "id": "110", "title": "Element Title", "entity type": "<entity_type_machine_name>" } } ] } }</pre> The array is returned consistently, including where a single element is mapped. Where elements of several entity types are mapped to the same ESF, each entity type machine name holds its own array. The same structure applies to both `old_value` and `new_value`. (2) Completeness of logged events. Element relations created via the Add button in an ESF on the element details page are recorded in the timeline. These relations were not logged previously, so the resulting change was absent from both the element timeline and the timeline API response. Relations created via the edit form and via enrichment were and remain logged.
Client action required	(1) Update automations that read ESF values from timeline `old_value` / `new_value` payloads to iterate an array per entity type machine name rather than reading a single object. Logic that accesses `field_value.<entity_type_machine_name>.field_value` directly will no longer resolve. (2) Expect a higher volume of timeline records for entity types using ESFs, as relation changes made via the Add button on the details page are now included. Automations that reconcile, count, or diff timeline records should be reviewed against a non-production (STAGE) environment before relying on historical comparisons. Automations that do not read ESF values from timeline data are not affected.

3.24.3 minor release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.24.3 minor release. Note that the same changes are also included in the 3.25.1 minor release. Refer to the release notes for more detailed information on the release.

(1) NUC-19248

The 3.24.3 release addresses a set of minor API inconsistencies across the platform, normalising response formats, correcting data types, tightening validation enforcement, and aligning HTTP error handling. The changes below are grouped by the endpoints they affect.

Field properties endpoints

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.

Element GET endpoints

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.

Element POST/PUT endpoints

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.

Table data PUT endpoint

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.

All endpoints — HTTP method handling and error format

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.

Additional changes — no action required

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.

(2) NUC-18375:

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	Improved the performance and accuracy of the full-text search that powers the query filter parameter. Requests using this parameter previously could take a long time to complete or time out entirely on systems with a large number of entity types and fields. The following behaviour has changed: Partial word matching now works for multi-word searches. Previously, a search for a partial term only matched when a single word was entered. A search such as ?query=qua%20lea returned no results, while ?query=qua worked as expected. Multi-word partial searches now match correctly: ?query=qua%20lea returns elements containing "Quantum Leap". Matching now starts from the beginning of a word. Search terms are matched against the start of each word rather than against any position within a word. A search for ?query=quan continues to return elements containing "Quantum", but a search for a fragment from the middle of a word may now return fewer results than before. Result relevance and ordering have improved. Corrections to how title, abstract, and description fields are weighted mean the most relevant elements now appear higher in the result set. The order of results returned for a given search term may differ from previous releases. Searches no longer fail outright under heavy load. A time limit now applies to each search request. Where the limit is reached, a partial result set is returned instead of an error, keeping integrations running rather than failing the request. Number field values are now correctly searchable. Values stored in number fields and in single-line input fields containing numbers are now returned reliably in search results.
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.

3.24.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.24.0 major release. Refer to the release notes for more detailed information on the release.

(1) NUC-15523

Implication	Description
Category	Support of custom submission fields in idea POST/PUT endpoints, and addition of a new filter parameter
Change type / endpoint	Non-breaking: /api/itonics_idea.json POST and /api/itonics_idea/{id}.json PUT endpoints, and /api/itonics_idea.json?camp_id={id} GET endpoint
Description of change	Enriched the POST and PUT endpoints for the itonics_idea type to now also support the push of campaign-specific, custom submission fields New filter parameter to more easily retrieve all submission data (itonics_idea) for a particular campaign element {camp=id}.
Client action required	Existing automations must not be updated right away to reflect the changes. However, with the support of the additional custom submission fields, automations pushing ideation data into the ITONICS system can be updated to enrich even more data automatically via API.

(2) NUC-15862

Implication	Description
Category	Addition of new timeline filter parameters and more granular timestamp tracking
Change type / endpoint	Non-breaking: /api/timeline.json?entity_type={entity_type}, and /api/timeline.json?entity_type={entity_type}&entity_id={entity_id} GET endpoints
Description of change	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)
Client action required	Ensure existing automations are updated to ensure alignment with the updated validation for both endpoints.

(3) NUC-16354

Implication	Description
Category	Update of date field GET outputs and POST/PUT inputs formats, and date filter input formats
Change type / endpoint	Breaking: All element, campaign, submission GET endpoints retrieving, a.o. date field information, All GET endpoints utilizing the following meta controls from_date, to_date, and range, All GET endpoints utilizing the following filter parameters Date fields, Create date, and Update date, All element and submission POST and PUT endpoints pushing, a.o. date field information
Description of change	Updated the expected date format to consistently expect YYYY-MM-DD for all mentioned endpoints from MM/DD/YYYY Ensure aligned ISO timestamp format across all GET (including filter parameters and meta controls), POST, and PUT endpoints for date field input and output fields
Client action required	Ensure existing automations are updated to ensure alignment with the updated validation for both endpoints.

(4) NUC-17971

Implication	Description
Category	Implementation of new system log endpoints and enrichment of ussr statistic endpoints for improved enterprise-tier governance and monitoring
Change type / endpoint	Non-breaking: New GET endpoints /api/system_logs/role-permission-configuration.json, /api/system_logs/role-configuration.json, /api/system_logs/user-role-configuration.json, /api/system_logs/share-permission-log.json, and And enriched GET endpoints /api/user_stats.json?type=auth_log_success, and /api/user_stats.json?type=auth_log_failed
Description of change	Introduced new endpoints to retrieve system log data, and Enriched existing user statistics endpoint to support more granular retrieval of authentication attempts (successful and failed login attempts)
Client action required	Existing automations must not be updated right away to reflect the changes. However, with the introduction of additional API GEt endpoints for audit logs, improved monitoring and enterprise-tier audit and governance processes can be established through continuous retrieval of log data via API.

3.23.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.2 major release. Refer to the release notes for more detailed information on the release.

(1) NUC-16712

Implication	Description
Category	Introduction of new GET and PUT endpoints
Change type / endpoint	Non-breaking: /api/table_data.json?entit_type{entity_type} and /api/table_data.json?entit_type{entity_type}&entity_id={id} GET endpoints /api/entity_field_properties.json?type={entity_type}&config=table_data GET endpoint and new /api/table_data.json?entity_type={entity_type}&entity_id={id} PUT endpoint introduced.
Description of change	Introduced new endpoints to retrieve table data, and Retrieve table data structure (configuration) to be able to PUT (update) table data for a specific element
Client action required	Existing automations must not be updated right away to reflect the changes. However, with the introduction of the additional table endpoints, more thorough reporting on table data is possible, as well as automating updates of table data via API.

(2) NUC-17203

Implication	Description
Category	Validation update for endpoints
Change type / endpoint	Breaking: Requires client action to prevent integration failure if utilizing the /api/itonics_idea.json and /api/itonics_idea/{id}.json POST/PUT endpoints in automations.
Description of change	Creator validation: the system now validates that the username value provided in the creator property must be a valid participant of the associated campaign
Client action required	Ensure existing automations are updated to ensure alignment with the updated validation for both endpoints.

3.22.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.22.0 major release . Refer to the release notes for more detailed information on the release.

(1) NUC-17010 and NUC-17143

Implication	Description
Category	Endpoint updates, GET output format updates, property updates, introduction of further GET meta controls
Change type / endpoint	Breaking: Requires client action to prevent integration failure if utilizing the /api/roadmap/{id}.json GET endpoint in automations.
Description of change	Renamed properties: entity_id to element_id, (element) label to title, (element) content to abstract, and (milestone) label, content, and start date to milestone_title, milestone_description, and milestone_date Aligned milestone start- / end date format: now YYYY-MM-DD Added new auto-generated milestone ID milestone_generated_id as a reference Added new property is_synced to indicate if an element roadmap record is controlled by synchronized roadmap dates Introduced (custom) milestone fields configured from entity-specific milestone configuration Global milestone type information is still listed in utility_data Connection information must now be retrieved via /api/roadmap/{id}.json?type=connection Introduced page and limit meta controls for roadmap endpoints
Client action required	Ensure existing automations are updated to reflect the updated property labels and output formats of the /api/roadmap/{id}.json endpoint, and targeting the correct (sub-)endpoint, e.g. for retrieval of connection type information (/api/roadmap/{id}.json?type=connection), and page and limit parameters used to maintain performance

(2) NUC-16616 and NUC-16617

Implication	Description
Category	Added more information to existing endpoints and introduction of new endpoint
Change type / endpoint	Non-breaking: Additional information provided in /api/{entity_type}.json and /api/{entity_type}/{id}.json /api/user.json and /api/user/{id}.json GET endpoints and new /api/user_field_properties.json GET endpoint introduced.
Description of change	Added UIDs for creator, editor followers, etc. for facilitated reference in element GET endpoint response Introduced further information, a.o. user_roles, profile_image, and other default user fields for consistency in user GET endpoints Added custom user field information; introduced new /api/user_field_properties.json GET endpoint to retrieve (custom) user field configuration
Client action required	Existing automations must not be updated right away to reflect the changes. However, esp. with the introduction of the additional user field properties, a more thorough reporting on user data via the GET API can be tackled.

3.21.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.21.0 major release . Refer to the release notes for more detailed information on the release.

(1) NUC-16338

Implication	Description
Category	GET output format update
Change type / endpoint	Breaking: Requires client action to prevent integration failure if utilizing /api/{entity_type}.json and /api/{entity_type}/{id}.json GET endpoints in automations.
Description of change	Aligned output format of hierarchy-/segment field options in the element GET endpoint responses with our standard format Before: “field_machine_name” { “segment_field_machine_name_entity_segment”: “string”} After: “field_machine_name” { “segment_field_machine_name_entity_segment”: {“field_option_id”: {“label”: “string”, “parent”: “parent_segment_option_id”}}
Client action required	Ensure existing automations are updated to reflect the adjusted output format for segment- / hierarchy fields in the /api/roadmap/{id}.json endpoint respons

(2) NUC-16056

Implication	Description
Category	Added more information to existing endpoints
Change type / endpoint	Non-breaking: Additional information provided in /api/{entity_type}.json and /api/{entity_type}/{id}.json, as well as /api/itonics_idea.json and /api/itonics_idea/{id}.json GET endpoints.
Description of change	New properties for external submitter information: "field_ext_firstname": "string", "field_ext_lastname": "string", "field_ext_email": "email_string"
Client action required	Existing automations must not be updated right away to reflect the changes. However, a more thorough reporting on externally submitted element data via the GET API can be tackled.

(3) NUC-15075

Implication	Description
Category	Introduction of new endpoints, and added more information to existing endpoints
Change type / endpoint	Non-breaking: New GET endpoints (re-)introduced: /api/itonics_campaign_tr3.json and /api/itonics_campaign_tr3/{id}.json, /api/itonics_idea.json and /api/itonics_idea/{id}.json, as well as /api/entity_field_properties.json?type=itonics_campaign_tr3&entity_id{id}, respectively /api/entity_field_properties.json?type=itonics_idea&camp_id={id}
Description of change	(Re-) provided for basic campaign GET information via /api/itonics_campaign_tr3.json and /api/itonics_campaign_tr3/{id}.json endpoints Included visibility information (and also added element GET endpoints if an {entity_type} has visibility enabled) Introduced (default) submission fields configured per campaign element, provided via /api/{entity_type}.json and /api/{entity_type}/{id}.json endpoints The submission field configuration can be retrieved via /api/entity_field_properties.json?type=itonics_campaign_tr3&entity_id{id}, respectively /api/entity_field_properties.json?type=itonics_idea&camp_id={id}
Client action required	Existing automations must not be updated right away to reflect the changes. However, more thorough reporting on ideation use cases via the GET API can be tackled, as well as building on the POST/PUT endpoints introduced in 3.23.0.

3.20.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.20.0 major release . Refer to the release notes for more detailed information on the release.

(1) NUC-15522

Implication	Description
Category	Introduction of new endpoints, and added more information to existing endpoints
Change type / endpoint	Non-breaking: New PUT/POST endpoints introduced for campaign submissions
Description of change	Introduced new endpoint to create campaign submissions via API, covering (default) submission fields: /api/itonics_idea.json Introduced new endpoint to update campaign submissions via API, covering (default) submission fields: /api/itonics_idea/{id}.json
Client action required	Existing automations must not be updated right away to reflect the changes. However, now API automations can be tackled to push external idea data into the ITONICS application.

3.19.0 major release

This section provides an overview of any breaking or noteworthy changes introduced to the ITONICS REST API with the 3.19.0 major release . Refer to the release notes for more detailed information on the release.

(1) NUC-14814

Implication	Description
Category	Endpoint updates, introduction of new endpoints
Change type / endpoint	Breaking: Requires client action to prevent integration failure if utilizing the /api/{entity_type}.json or /api/{entity_type}/{id}.json GET endpoints to retrieve timeline/history in automations.
Description of change	Removed the timeline data from the existing endpoints /api/{entity_type}/{id}.json and /api/{entity_type}.json Instead, introduced new, dedicated GET endpoints for timeline data /api/timeline.json?entity_type={entity_type} /api/timeline.json?entity_type={entity_type}&entity_id={entity_id} Also, introduced a new permission Access the resource timeline via API (global permission) to control timeline data access
Client action required	Ensure existing automations are updated to point to the correct new GET endpoint(s) to keep on retrieving timeline data.

Note: No significant changes worth communicating from lower release versions.