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

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.

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.