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