TM Rule Rerun – Changed
The Rule Rerun API is now subject to a per-tenant rate limit.
The Rule Rerun API is now subject to a per-tenant rate limit.
The Rule Schedule API is now subject to a per-tenant rate limit.
The Batch Upload API is now subject to per-tenant rate limits.
The Transaction API is now subject to a per-tenant rate limit.
The maximum number of EntityIds accepted per request is raised from 10 to 100. Requests above the new limit are still rejected with a validation error. Response shape is unchanged.
/entitydataquery/api/v2/entity/drafts/namesNew V3 Entity endpoints are now available. These replace the existing V1/V2 entity endpoints and introduce two key improvements: support for multiple addresses per entity in SearchCriteria, and per-configuration-set targeting when toggling Ongoing Screening.
Additionally, the ConfigurationSetId field is now exposed in the Ongoing Screening results callback, enabling adapters to identify which configuration set a screening result belongs to.
New endpoint that returns a named subset of an entity draft's properties for up to 10 drafts in a single request. Each result carries the draft's id, type, and only the top-level property keys named in the request. Requested keys that don't exist on a draft are omitted, and drafts that don't exist or that the caller cannot access are omitted from the response.
/entitydataquery/api/v2/entity/drafts/partial-propertiesGraphQL responses — including auth-denied ones — from both EntityData subgraph hosts now include the Platform security headers Strict-Transport-Security and Content-Security-Policy.
/graphqlEntity draft/entity update validation now honours Policy ExternalDataGroupProvider rules for data group fields when creating external adapter validation requests. Request/response schema is unchanged; affected command endpoints now correctly reject invalid data group rows returned by the external provider.
Entity draft/entity update validation now sends data group fields to external adapter providers as grouped requests (one request per collection row per provider) instead of individual single-field requests. Request/response schema is unchanged; validation error messages returned to callers are unaffected.