Strise Connect API Docs

Changelog

API Changelog: 2026-03-25

This update enhances risk detection by introducing several new values to the FlagKind enum. These new flags help identify risks based on an entity's industry, jurisdiction, legal form, and network connections. This is a non-breaking change.

New Features

  • Added new values to FlagKind for enhanced risk detection We have added six new flags to the FlagKind enum, which is available on all types implementing the EntityLike interface (e.g., Company, BusinessPerson). These additions provide more granular insight into potential risks associated with an entity and its network.

    The new flags are:

    • HIGH_RISK_INDUSTRIES: The entity operates in an industry defined as high-risk in your team settings.
    • HIGH_RISK_JURISDICTIONS: The entity or its network has connections to high-risk jurisdictions.
    • HIGH_RISK_LEGAL_FORMS: The entity or its network has a legal form defined as high-risk in your team settings.
    • PEP_CONNECTIONS: The entity or its network has connections to Politically Exposed Persons (PEPs).
    • RCA_CONNECTIONS: The entity or its network has connections to Relatives and Close Associates (RCAs).
    • SANCTION_CONNECTIONS: The entity or its network has connections to sanctioned entities.

API Changelog: 2026-03-24

This update continues our effort to make relationship data more structured and easier to query. We are deprecating the generic relationships field across all entity types in favor of specific fields like roles, holdings, and beneficialOwnerships. As part of this, we have added these specific fields to the CustomBusinessPerson type to align it with other entities. These changes are non-breaking, but we encourage developers to update their queries to use the new, more explicit fields.

Relationship Data Refinements

  • Deprecation of the generic relationships field The relationships field has been deprecated on the Company, BusinessPerson, CustomBusinessPerson, PrivatePerson, and EntityLike types. This is a non-breaking change.

    We are moving towards a more structured and explicit way of representing entity relationships. Instead of using the generic relationships field, you should now use the specific fields that correspond to the type of relationship you need.

    For example, on Company and BusinessPerson, you should now use:

    • roles
    • shareholders (on Company) or holdings (on BusinessPerson)
    • beneficialOwnerships

    Please update your queries to use these more specific fields for better performance and clarity. The relationships field will be removed in a future version.

  • New relationship fields added to CustomBusinessPerson To provide a consistent way of querying relationships, we have added the following new fields to CustomBusinessPerson:

    • roles: To query for roles the person holds in companies.
    • holdings: To query for the person's direct company ownership.
    • beneficialOwnerships: To query for companies where the person is a beneficial owner.

    These new fields replace the now-deprecated relationships field on CustomBusinessPerson.

API Changelog: 2026-03-20

New importCompany mutation for onboarding companies. In a single call you can import a company, set a risk level and review validity date, and add it to monitoring.

New Features

  • importCompany mutation Use importCompany to onboard companies from another system into Strise. It takes a companyId and optionally:

    • A riskLevel and validUntil date to create an initial review.
    • addToMonitoring: true to start monitoring the company.

    Example:

    mutation ImportCompany {
      importCompany(
        where: {
          company: "c-12345"
          riskLevel: HIGH
          validUntil: "2027-03-20T00:00:00Z"
          addToMonitoring: true
        }
      ) {
        success
      }
    }

API Changelog: 2026-03-10

This release includes non-breaking improvements to the CustomOwnersInput type, making the deprecated customPersons field optional to improve ease of use.

Improvements

  • customPersons field on CustomOwnersInput is now optional. We have updated the customPersons field on the CustomOwnersInput type.

    • The field is no longer required, as its type has changed from [CustomPersonOwnershipInput!]! to [CustomPersonOwnershipInput!].
    • If omitted, the field will now default to an empty array ([]) instead of being null.

    This is a non-breaking change. Note that this field remains deprecated. The recommended approach is to use the customPersonCreate mutation and subsequently add the person as an owner through the businessPersons field.

API Changelog: 2026-03-10

This update introduces several deprecations aimed at improving the way custom companies and their ownership are managed. We've replaced generic input fields with more specific ones to provide better structure and clarity. While these changes are non-breaking, we recommend updating your integrations to use the new fields.

Custom Entity Management

  • shareholders field deprecated in CustomCompanyCreateInput and CustomCompanyUpdateInput The shareholders field on the CustomCompanyCreateInput and CustomCompanyUpdateInput objects has been deprecated. This field was used to define owners when creating or updating a custom company. It is being replaced by two more specific fields, companyShareholders and personShareholders, to distinguish between corporate and individual owners.

    To migrate, you should now separate your list of owners into two distinct lists for the companyShareholders and personShareholders fields respectively.

  • customPersons field deprecated in CustomOwnersInput The customPersons field on the CustomOwnersInput object has been deprecated. This field allowed for the inline creation of a person while defining ownership. The new, recommended workflow is to first create the person using the customPersonCreate mutation and then use the returned BusinessPersonId to add them as an owner via the businessPersons field. This change provides a more explicit and robust way to manage custom persons as distinct entities.

API Changelog: 2026-03-09

This update introduces new fields on the Company and BusinessPerson types to provide enhanced data provenance. You can now access metadata about user edits, such as who made a change and when it was made. This allows you to distinguish between official registry data and data modified within the Strise platform. All changes are non-breaking.

Features

  • Introducing Edit Metadata for Key Entity Fields We've added new "V2" fields for several data points on Company and BusinessPerson to provide more context about the data's origin. These new fields return an object containing the data value itself, plus an editMetadata object if the data has been modified by a user. This is useful for understanding if a value comes directly from an official registry or has been edited.

    These new fields also accept an ignoreEdits: Boolean argument, which allows you to retrieve the original, unedited registry data.

    The following fields have been added or enhanced:

    • BusinessPerson.birthDateV2: A new field of type ConnectBirthDate that provides a person's birth date and year, along with editMetadata. This is the new preferred way to access birth date information.
    • Company.inceptionV2: A new field of type ConnectInceptionDate that provides a company's inception date and its editMetadata. This should be used in place of the inception field.
    • Company.organisationFormCodeV2: A new field of type ConnectOrganisationFormCode that includes the organization form code and its editMetadata. This replaces the older organisationFormCodes field.
    • Company.industriesV2: The ConnectIndustryCode type returned by this field now also includes editMetadata for each industry code. The older industries field is deprecated.

API Changelog: 2026-03-06

This update introduces support for customer-facing forms for PrivatePerson entities, extending the existing functionality previously available only for companies. This includes new mutations for sending, canceling, and managing forms for private persons. A new documents field has also been added to the PrivatePerson type to support this feature.

Features

  • Customer-facing forms for Private Persons We have extended our customer-facing forms feature to now support PrivatePerson entities. This mirrors the existing functionality for Company entities and includes a new set of mutations:

    • sendPrivatePersonForm: Sends a form to a specified recipient for a private person.
    • cancelPrivatePersonForm: Cancels an in-progress form.
    • createPrivatePersonFormUrl: Creates a shareable URL for an active form.
    • attachPrivatePersonFormInstance: Attaches an externally completed form instance to a private person.
  • New documents field on PrivatePerson A new documents field has been added to the PrivatePerson type. This field returns a list of documents related to the person, such as form instances and document orders. The id from these documents is required to use the new cancelPrivatePersonForm and createPrivatePersonFormUrl mutations.

API Changelog: 2026-03-05

We've added a new field to the Company type to better represent relationships between main companies and their sub-units. This is a non-breaking change.

New Features

  • Parent Company ID for Sub-Units We've added the parentCompanyId field to the Company type. This field provides the identifier for a parent company when the queried company is a sub-unit (e.g., a branch or a business unit registered under a main legal entity). The field will be null if the company is not a sub-unit, helping you to better identify and navigate corporate structures.

API Changelog: 2026-02-23

This update includes a minor, non-breaking improvement to provide more clarity on an upcoming feature related to monitoring alerts. We've added a descriptive comment to an enum value to prepare for future functionality and prevent confusion. The update also introduces a set of generic, non-country-specific legal forms. This enhancement allows for better classification of custom companies or companies from jurisdictions not explicitly supported by our country-specific codes. This is a non-breaking change.

Improvements

  • Clarified status of COMPANY_INFORMATION alert kind We've added a description to the COMPANY_INFORMATION value in the DatasetKind enum. This description clarifies that this alert kind is currently under development and not yet active. Alerts with this kind will not contain any change data for the time being. This is a preparatory, non-breaking change for a future feature.

  • Added Global Legal Form Kinds We've expanded the LegalFormKind enum with new generic values to represent common company structures in a globally-recognized, non-country-specific way. This is particularly useful when creating or updating custom companies where a precise, country-specific legal form is not available or applicable.

    The following new values have been added to the LegalFormKind enum:

    • GLOBAL_COOPERATIVE
    • GLOBAL_FOUNDATION
    • GLOBAL_GOVERNMENT_ENTITY
    • GLOBAL_LIMITED_COMPANY
    • GLOBAL_LIMITED_PARTNERSHIP
    • GLOBAL_NON_PROFIT
    • GLOBAL_OTHER
    • GLOBAL_PARTNERSHIP
    • GLOBAL_PUBLIC_LIMITED_COMPANY
    • GLOBAL_SOLE_PROPRIETORSHIP
    • GLOBAL_TRUST

    As this is an additive change to an enum, it is non-breaking and will not impact existing integrations.

API Changelog: 2026-02-18

This update introduces the ability to programmatically create reviews for private persons. This provides feature parity with the existing review creation functionality for companies, enabling more comprehensive automation of compliance workflows.

Features

  • Added mutation to create reviews for private persons You can now programmatically initiate a review for a PrivatePerson using the new reviewPrivatePersonCreate mutation. This works similarly to the existing reviewCompanyCreate mutation for companies. Pass the PrivatePersonId to start a review, and the API will return a PrivatePersonReviewPayload containing the success status and the resulting risk class.

API Changelog: 2026-02-13

This update introduces a new mutation, alertUpdate, allowing you to programmatically manage the state of monitoring alerts. This is a non-breaking change.

New Features

  • New alertUpdate mutation for managing alerts You can now programmatically update the state of one or more monitoring alerts using the new alertUpdate mutation. This allows you to mark alerts as RESOLVED or UNRESOLVED in bulk by providing a list of alert IDs. This change simplifies alert lifecycle management within your applications.

    The mutation uses the new AlertUpdateInput and returns an AlertUpdatePayload.

    Example Usage:

    mutation UpdateAlerts {
      alertUpdate(where: {
        ids: ["alert-id-1", "alert-id-2"],
        state: RESOLVED
      }) {
        success
      }
    }

API Changelog: 2026-02-12

This update introduces a powerful new Custom Risk Fields feature. You can now define, assign, and query your own risk attributes for companies and private persons, enabling more tailored and comprehensive risk assessments based on your organization's specific criteria.

New Features

  • Manage and query Custom Risk Fields on entities

    You can now manage and retrieve custom risk data to enrich entity profiles. This feature allows for more flexible and specific risk scoring tailored to your needs. The workflow is as follows:

    • Discover available fields: Use the new customRiskFields query to get a list of all custom risk field definitions configured for your team. This will return each field's ID, name, type (e.g., SINGLE_SELECT, MULTI_SELECT), and available options.

    • Assign values to an entity: Use the new entityUpdateCustomRiskField mutation to set or update the value of a custom risk field for a specific company or person. You provide the entity's ID, the risk field's ID, and the selected option ID(s).

    • Read assigned values: The assigned custom risk field values for an entity can be retrieved via the customRiskFields field, now available on the Company and PrivatePerson types.

API Changelog: 2026-02-11

This update introduces a new mutation, attachFormInstance, which allows for associating an existing, externally initiated form instance with a specific company in the system. This provides greater flexibility for workflows where forms are handled outside of the standard API process.

Features

  • New attachFormInstance mutation A new mutation has been added to enable linking a form instance to a company. This is useful when a form is initiated through an external process and needs to be programmatically associated with a company record.

    The mutation attachFormInstance requires the companyId and the formInstanceId to be attached. It returns a boolean success flag to indicate if the operation was successful.

    Example Usage:

    mutation AttachFormInstanceToCompany($companyId: CompanyId!, $formInstanceId: FormInstanceId!) {
      attachFormInstance(where: {
        companyId: $companyId,
        formInstanceId: $formInstanceId
      }) {
        success
      }
    }

    Associated Schema Changes:

    • New Mutation field: attachFormInstance(where: AttachFormInstanceInput!): AttachFormInstancePayload!
    • New Input type: AttachFormInstanceInput
    • New Type: AttachFormInstancePayload

API Changelog: 2026-02-10

This update introduces new capabilities for managing customer-facing forms. You can now programmatically generate a shareable URL for an existing form and cancel forms that are in progress. We've also updated the description of a related field to improve clarity.

Features

  • Added createFormUrl mutation to generate form URLs. You can now create a shareable URL for an active customer-facing form. This is useful when you need to re-send a form link to a customer. Use the createFormUrl mutation with a companyId and documentId. You can also specify an optional timeToLive for the URL.

  • Added cancelForm mutation to cancel active forms. The new cancelForm mutation allows you to cancel an active customer-facing form that is currently in progress. This action requires the companyId and the documentId of the form instance. The associated document's status will be set to CANCELLED.

  • Clarified Company.documents field description. The description for the Company.documents field has been updated to clarify that it returns a list of both completed documents and document orders that are in progress. This is a non-functional change intended to improve documentation clarity in relation to the new form management capabilities.

API Changelog: 2026-02-10

This update introduces a new status for document uploads, allowing for more granular tracking of a document's lifecycle. This is a non-breaking change.

Documents

  • New CANCELLED status for document uploads The DocumentStatus enum has been expanded with a new CANCELLED value. This status will be returned in the status field of the Document type when a document upload has been cancelled by a user or the system. This provides more detailed information about the state of a document, in addition to the existing statuses: PENDING, IN_PROGRESS, SUCCESS, and FAILED. While this is a non-breaking change, we recommend updating your client to handle the new CANCELLED enum value.

API Changelog: 2026-02-09

This update introduces a new mutation for generating alerts in sandbox environments, providing a way for developers to test their alert-handling logic. This is a non-breaking update.

New Features

  • Generate sandbox alerts for testing A new sandboxAlertGenerate mutation has been added. This mutation allows you to programmatically trigger PEP or sanction alerts for any monitored company within your sandbox environment. It's designed to help you test and validate your application's response to different alert scenarios. You can specify the entity to alert on, the type of alert (PEP or SANCTION), and whether to add or remove a screening hit to trigger the alert. This feature is exclusively available in the sandbox environment.

API Changelog: 2026-02-06

This update introduces the ability to query user-defined custom risk fields on Company and PrivatePerson entities. This allows you to retrieve values for custom risk criteria, enhancing tailored risk assessments. All changes in this release are non-breaking.

New Features

  • Query Custom Risk Fields on Entities You can now retrieve the values for custom risk fields that have been configured and assigned to an entity. This is useful for integrating your organization's specific risk criteria into your applications.

    • A new customRiskFields field has been added to the Company and PrivatePerson types.
    • This field returns an array of EntityCustomRiskField objects. Each object contains the riskField definition and the selectedOptions for that entity.
    • This change introduces several new supporting types:
      • EntityCustomRiskField: Associates a risk field and its selected options with an entity.
      • CustomRiskField: Defines a custom risk field, including its name, kind, and all possible options.
      • CustomRiskFieldKind: An enum that specifies if the field is a SINGLE_SELECT or MULTI_SELECT.
      • CustomRiskFieldOption: Represents a possible option for a custom risk field.

API Changelog: 2026-01-19

This update introduces a comprehensive credit reporting feature. You can now order credit reports for companies and retrieve detailed credit score information directly through the API. This enhancement provides valuable financial insights, including credit ratings, payment remarks, and collateral summaries.

New Features

  • Added credit reporting for companies This update adds the ability to order and query credit reports for companies.

    • You can now order a credit report for a company using the new companyCreditReportOrder mutation. This mutation takes a company ID and returns a CreditReportPayload containing the result.
    • The Company type now has a creditScore field, which provides data from the most recently ordered credit report. This field will be null if no report has been ordered.

    This feature is supported by several new types:

    • CreditReportPayload: The response object for the companyCreditReportOrder mutation. Contains:

      • success: Whether the credit report was successfully ordered.
      • company: The company for which the credit report was ordered.
      • creditScore: The credit score data.
    • CreditScore: Contains detailed credit information:

      • reportDate: The date when the credit report was ordered.
      • rating: The international credit rating (A-E).
      • ratingDescription: Description of the rating.
      • creditRating: The numerical credit score/rating value.
      • creditLimit: The company's credit limit.
      • currencyCode: Currency code for monetary values in this report.
      • hasPaymentRemarks: Whether the company has any payment remarks.
      • remarks: Summary of unsettled payment remarks.
      • partiallySettledRemarks: Summary of partially settled payment remarks.
      • voluntaryCollateral: Summary of voluntary collateral.
      • scoreUnavailableReason: Reason why the credit score is unavailable, if applicable. Only present when the company could not be scored.
    • CreditRating: An enum representing the international credit rating scale:

      • A: Very Low Risk (score 71-100)
      • B: Low Risk (score 51-70)
      • C: Moderate Risk (score 30-50)
      • D: High Risk (score 1-29)
      • E: No Rating
    • PaymentRemarksSummary: Provides a summarized count and total amount for payment remarks.

    • CollateralSummary: Provides a summarized count and total amount for voluntary collateral.

    Example: Order a new credit report

    mutation OrderCreditReport {
      companyCreditReportOrder(where: { id: "your-company-id" }) {
        success
        company {
          id
          name
        }
        creditScore {
          reportDate
          rating
          ratingDescription
          creditRating
          creditLimit
          currencyCode
          hasPaymentRemarks
          scoreUnavailableReason
          remarks {
            count
            totalAmount
          }
          partiallySettledRemarks {
            count
            totalAmount
          }
          voluntaryCollateral {
            count
            totalAmount
          }
        }
      }
    }

    Example: Query existing credit score for a company

    query GetCompanyCreditScore {
      company(where: { id: "your-company-id" }) {
        name
        creditScore {
          reportDate
          creditLimit
          creditRating
          rating
          ratingDescription
          hasPaymentRemarks
          remarks {
            count
            totalAmount
          }
          partiallySettledRemarks {
            count
            totalAmount
          }
          voluntaryCollateral {
            count
            totalAmount
          }
          currencyCode
          scoreUnavailableReason
        }
      }
    }

API Changelog: 2026-01-16

This update adds a new field to the Review object type. This enhancement allows for storing self-assessment notes from a review, providing additional context for due diligence and compliance records.

New Features

  • New selfAssessment field on Review A new field, selfAssessment, of type String has been added to the Review object. This field can be used to retrieve the self-assessment notes that were captured during the review process.

API Changelog: 2026-01-14

This update enhances our risk assessment capabilities by providing more context around how risk scores are calculated. We've introduced a new status to indicate when a score could not be determined due to missing data, and a corresponding INCONCLUSIVE risk level. These changes are non-breaking.

Risk Assessment

  • Added status field to RiskScoreResult to clarify score calculation To provide more insight into risk calculations, we've added a new status field to the RiskScoreResult object. This field uses the new RiskScoreStatus enum to indicate whether a score was calculated successfully or if the necessary data was unavailable.

    This helps differentiate between a score of 0 due to low risk (CALCULATED) and a score of 0 due to a lack of data (MISSING_DATA).

    The new status field is available on all fields that return a RiskScoreResult, such as RiskCalculationResult.countryScore and RiskCalculationResult.industryScore.

    "Indicates whether data was present for a risk score calculation"
    enum RiskScoreStatus {
      "Data was present and the score was calculated normally"
      CALCULATED
    
      "No data was available for this risk category"
      MISSING_DATA
    }
    
    "A risk score with its matched values that contributed to the score"
    type RiskScoreResult {
      score: Int!
      matchedValues: [String!]!
    
      "Indicates whether data was present for calculation or if it was missing"
      status: RiskScoreStatus!
    }
  • New INCONCLUSIVE value added to RiskLevelKind enum We have added a new INCONCLUSIVE value to the RiskLevelKind enum. This new level is used when a final risk level cannot be determined because critical data required for the calculation is missing. Developers should update any client-side logic that consumes the RiskLevelKind enum to handle this new value.

    enum RiskLevelKind {
      # ... existing values
      "Inconclusive risk level - critical data is missing for risk calculation"
      INCONCLUSIVE
    }

API Changelog: 2026-01-13

This update enhances the automated risk calculation by introducing a new score component based on an entity's Relatives and Close Associates (RCAs). This change is non-breaking.

Additions

  • Added RCA Count Score to Risk Calculation The RiskCalculationResult type now includes the rcaCountScore field. This field provides a detailed risk score (of type RiskScoreResult) based on the number of Relatives and Close Associates (RCAs) found for an entity, contributing to a more granular total risk assessment.

API Changelog: 2026-01-06

This update introduces a comprehensive suite of features for advanced risk management and entity lifecycle tracking. You can now perform and query detailed reviews for private persons, access both calculated and user-assessed risk levels, and track an entity's portfolio status. These changes affect the Company, PrivatePerson, and Review types, and introduce new queries for private person reviews. This is a non-breaking update.

Enhanced Risk and Review Management

  • New risk assessment fields for Company and PrivatePerson We have added several new fields to provide more granular risk information. The automatedRiskLevel field on Company is now deprecated.

    • calculatedRiskLevel: A new object on Company that provides a detailed breakdown of the automated risk calculation, including scores for country, industry, sanctions, and more. This field replaces the deprecated automatedRiskLevel.
    • userAssessedRiskLevel: A new field on both Company and PrivatePerson that stores the risk level (e.g., HIGH, MEDIUM, LOW) assigned by a user during a review.
    • nextScheduledReviewDate: A new field on both Company and PrivatePerson that shows the date for the next periodic review, which is based on the risk assessed in the latest review.
  • Added reviews for PrivatePerson You can now create and retrieve reviews for PrivatePerson entities, mirroring the existing functionality for companies.

    • PrivatePerson.reviews: A new field on the PrivatePerson type that returns a list of all completed reviews (PrivatePersonReview) for that person.
    • Query.privatePersonReview and Query.privatePersonReviews: New root queries to fetch a single PrivatePersonReview by its ID or list all private person reviews within a specified date range.
  • Expanded Review type The existing Review type (for companies) has been enhanced to store more contextual data from the review process.

    • calculatedRiskLevel: The calculated risk level at the time of the review.
    • userAssessedRiskLevel: The user-assessed risk level that was set during the review.
    • validUntilDate: The date until which the review is considered valid.

Entity Portfolio Status

  • Track entity status in your portfolio A new entityPortfolioStatusInfo field has been added to both the Company and PrivatePerson types. This allows you to track an entity's status within your internal workflow.
    • The entityPortfolioStatusInfo field returns an EntityPortfolioStatusInfo object, which contains the current status (e.g., PROSPECT, QUALIFIED, ACCOUNT), the previousStatus, and when it was last modifiedAt.
    • A corresponding entityStatus field has also been added to the Review type to capture the entity's portfolio status at the time the review was conducted.

API Changelog: 2025-12-19

This release includes a documentation improvement to clarify the behavior of the country filter when searching for persons. There are no breaking changes.

Improvements

  • Clarified behavior of PersonSearchInput.country The country field on the PersonSearchInput object now includes a description. This clarifies that the filter will be ignored if a developer provides a country code for a registry that is not supported by the API. This helps explain search results that might otherwise seem unexpected.

API Changelog: 2025-12-19

We've updated our API to support the new SNI 2025 industry classification standard. This is a non-breaking change that enhances our company data capabilities.

Improvements

  • Added SNI_2025 to IndustryCodeType A new enum value, SNI_2025, has been added to the IndustryCodeType enum. This represents the upcoming Swedish Standard Industrial Classification for 2025. You may encounter this value in the codeType field when querying for company industry information via the Company.industriesV2 field. As this is a non-breaking addition, existing integrations will not be affected, but we recommend updating clients to recognize this new value.

API Changelog: 2025-12-17

This update introduces a more robust and detailed way to handle entity addresses. We have added a new addresses field to all entity types, which provides a comprehensive list of addresses, each categorized by its type (e.g., postal, registered). The previous address field is now deprecated in favor of this new, more structured approach.

Improvements

  • Enhanced Address Information To provide more comprehensive and structured address data, we have introduced a new addresses field on Company, BusinessPerson, CustomBusinessPerson, and the EntityLike interface.

    This new field returns a list of all available addresses for an entity. To help distinguish between them, we've also added:

    • A new addressKind field to the Address type.
    • A new AddressKind enum with possible values: POSTAL, REGISTERED, TRADING, and VISITING.

    The existing address field is now deprecated and will be removed in a future version. We recommend updating your integrations to use the new addresses field to access this richer data and ensure future compatibility.

API Changelog: 2025-12-17

This update introduces enhancements to the EntityIdentifier type by adding a description field as well as a new UNKNOWN enum value to EntityIdentifierKind.

New Features

  • Added UNKNOWN emum value to EntityIdentifierKind. When the identifier cannot be determined to be of type PRIMARY or SECONDARY the identifier kind will be UNKNOWN.

  • Added description field on type EntityIdentifier. The description field provides additional details on the type of identifier.

API Changelog: 2025-12-16

This update introduces significant enhancements to our monitoring and alerts capabilities, providing more specific types and new filtering options. We've also improved the usability of adverse media screening fields. This release includes several breaking changes related to the alerts feature that require developer attention. The alert queries are still subject to change and breaking changes should still be expected.

Breaking Changes

  • Argument type for Query.alertData has changed. The alert argument on the Query.alertData field now accepts a value of type AlertId! instead of ID!. The new AlertId scalar provides a more specific identifier for alerts, improving type safety. You must update your queries to use this new type.

  • Type of monitoredEntity fields changed to MonitoredEntityLike. The monitoredEntity field on the AlertConnectionEdge and MonitoringChange types has been updated from EntityLike! to the new, more specific MonitoredEntityLike! interface. This change ensures that only entities that can be monitored are returned in this context.

New Features & Enhancements

  • Introduced MonitoredEntityLike interface for better type safety. We've added a new interface, MonitoredEntityLike, to specifically represent entities that can be monitored. The Company and PrivatePerson types now implement this interface, distinguishing them from other entities in monitoring-related queries.

  • Filter alerts by entity kind. The alerts query now accepts a new entityKind argument within the AlertsWhereInput object. You can use this to filter alerts for a specific type of entity, such as COMPANY or PRIVATE_PERSON, using the new EntityKind enum.

  • Improved pagination for ams fields. The pageInfo argument on PrivatePerson.ams (and other fields implementing EntityLike or MonitoredEntityLike) is now optional and includes a default value of { size: 20, offset: 0 }. This simplifies querying for the first page of adverse media events as the argument is no longer required. We've also added more detailed descriptions to the field and its arguments to clarify its usage.

API Changelog: 2025-12-10

This update introduces two non-breaking changes to improve data modeling. We've added a new field to the Company type to identify reference-only records and a new status to the DocumentStatus enum for better tracking of document uploads.

Features

  • New isReferenceOnly field on Company A new boolean field, isReferenceOnly, has been added to the Company type. This field will be true for company records that are created as a reference from another entity's relationship data (e.g., a shareholder from an unsupported country). These reference-only companies exist to complete the graph but have limited data available. You can use this flag to identify and handle these partial records appropriately in your application.

  • New IN_PROGRESS status for DocumentStatus The DocumentStatus enum now includes the value IN_PROGRESS. This new status indicates that a document upload has been initiated and is currently in the process of being uploaded. This provides more granular tracking between the PENDING and SUCCESS/FAILED states.

API Changelog: 2025-12-09

This update introduces a new mutation for creating private persons, providing more control over the data enrichment process. As this is a non-breaking change, all existing integrations will continue to work without modification.

New Features

  • New privatePersonCreateNoEnrich mutation A new mutation, privatePersonCreateNoEnrich, has been added to create a private person entity. Unlike the existing privatePersonCreate mutation, this new field does not automatically enrich the created person with data from external registries. It creates the person record using only the data you provide in the PrivatePersonCreateInput. This is useful when you have already verified the person's details, for example, by using the privatePersonRegistrySearch query, and want to create an entity with that exact data.

API Changelog: 2025-12-08

Improvements to the privatePersonSearch query

  • Added a new hasNin field to the PersonSearchInput query input that can be used to filter private persons that does or does not have a nin (national identification number).
  • Added pagination information in the search response, PageInfo, making it easier for the client to go through all the pages matching the query.
  • Order results by name ascending

API Changelog: 2025-12-05

This update introduces a new query, privatePersonRegistrySearch, allowing you to look up private individuals directly in official national registries. This provides a way to find and verify person data using a combination of identifiers before creating them in Strise.

New Features

  • New privatePersonRegistrySearch query

    The query uses the new PersonRegistrySearchInput type, which requires name and country, and accepts optional fields like nin (national identifier number), birthDate, and address details to refine the search. You must provide Name combined with one of the following: National ID Number, Birth Date, or an Address (requires Street Name with either Zip Code or House Number) to get a result.

    A successful search returns a ConnectPrivatePersonRegistrySearchResource object containing the person's details from the registry, such as their name, birth date, address, and official identifier.

    Example Query:

    query FindPersonInRegistry {
      privatePersonRegistrySearch(
        where: {
          name: "John Doe",
          country: "NO",
          birthDate: "1990-01-15"
        }
      ) {
        name
        birthDate
        address {
          addressLine
          city
          zipCode
        }
        identifier {
          value
          kind
        }
      }
    }

API Changelog: 2025-11-28

This update expands our Adverse Media Screening (AMS) capabilities by incorporating a new data source. This change is non-breaking, but you may want to update your client to handle the new event kind.

Additions

  • New Adverse Media Source: Dow Jones The AmsEventKind enum, which specifies the origin of an adverse media event, now includes the value DOW_JONES. When querying for adverse media via the ams field on an entity, you may now receive AmsEvent objects where the eventKind field is DOW_JONES.

API Changelog: 2025-11-27

Listing tags is now available for companies and private persons

New Features

  • Added tags field to Company and PrivatePerson types. This enables you to query for a list of tags added to these resources

API Changelog: 2025-11-05

New Features

  • Added shareholders and holdings fields to Company, and holdings to BusinessPerson New fields to retrieve shareholder and holding information for companies have been added. These fields return lists of Ownership objects, providing details about the direct shareholders and holdings of a company.

    In each Ownership object, you can find:

    • entity: The Company or BusinessPerson that is the shareholder, or Company that is being held.
    • totalSharePercentage: The total direct share percentage held by/in the entity.
    • shareClasses: A list that contains information about the share class and the share percentage held.
    • editMetadata: Metadata about potential edits that have been done to the item.
  • Added beneficialOwners field to Company, and beneficialOwnerships field to BusinessPerson These fields contain information about a company's beneficial owners and a business person's beneficial ownerships, respectively. They return lists of BeneficialOwnership objects, which include:

    • entity: The Company or BusinessPerson that is the beneficial owner/owned entity.
    • reasons: A list of reason enum values explaining why the entity is considered a beneficial owner.
    • editMetadata: Metadata about potential edits that have been done to the item.

For all these fields, you can use the ignoreEdits parameter to see the original, unedited data.

API Changelog: 2025-11-03

We've introduced a new way to retrieve information about corporate roles. You can now query for the roles held by a specific BusinessPerson or see all the roles associated with a Company. This is a non-breaking feature addition.

New Features

  • Added roles field to Company and BusinessPerson types A new roles field is now available on the Company and BusinessPerson types. This enables you to query for corporate role information, such as finding the CEO of a company or listing a person's board positions.

    This change introduces two new types: Role and RolePeriod.

    • The roles field returns a list of Role objects. Each Role includes the roleTitle, an isActive flag, the associated entity (the person or company), and a period object.
    • The RolePeriod object specifies the from and to dates for the role's tenure.
    • You can use the includePrevious: true argument to fetch historical roles in addition to current ones.

API Changelog: 2025-10-29

This update introduces a new capability to send customer-facing forms directly via the API. You can now trigger a form to be sent to a specific recipient's email and associate it with a company in your system. This is useful for processes like customer onboarding or information gathering.

Features

  • Added ability to send customer-facing forms A new sendForm mutation is now available. It allows you to programmatically send a predefined customer-facing form to an email recipient.

    To use this mutation, provide the companyId, the formId of the form you wish to send, and the recipient's details in the SendFormInput. Upon success, the API will return a SendFormPayload containing success: true and the unique formInstanceId for the form that was sent.

    This change introduces the following new types and fields:

    • Mutation: sendForm(where: SendFormInput!): SendFormPayload!
    • Input Type: SendFormInput, which requires companyId, formId, recipientEmail, and recipientName.
    • Payload Type: SendFormPayload, which returns a success boolean and the new formInstanceId.
    • Scalar IDs: CustomerFacingFormId to identify the form template, and FormInstanceId to identify the specific instance that was sent.

API Changelog: 2025-10-21

This update introduces a more structured way to access company industry codes. We have deprecated the industries field on the Company type and replaced it with the new industriesV2 field. This is a non-breaking change, but we encourage all developers to migrate to the new field to take advantage of the richer data.

Improvements

  • Company.industries field deprecated in favor of industriesV2 The industries field on the Company type is now deprecated and will be removed in a future API version. This field returned a simple list of strings representing industry codes.

    To provide more detailed information, we have introduced the new industriesV2 field. This field returns a list of ConnectIndustryCode objects, each containing the industry code, its description, and the codeType (e.g., NACE, SIC).

    We recommend updating your queries to use industriesV2 to access this more structured and informative data.

API Changelog: 2025-10-16

This update improves how you access Adverse Media Screening (AMS) data. We are deprecating the amsCount field on all relevant entities and introducing a more powerful ams field. This change allows you to retrieve detailed information about media events instead of just an approximate total count. This is a non-breaking change, but we encourage you to migrate to the new field.

Adverse Media Screening

  • Deprecated amsCount in favor of new ams field The amsCount integer field is now deprecated on the EntityLike interface and its implementing types: Company, BusinessPerson, and CustomBusinessPerson. It will be removed in a future release.

    We have introduced a new ams field which returns a paginated list of AmsEvent objects. This provides rich details for each adverse media article, such as the title, summary, publisher, and publication date. The new field provides more accurate and detailed results.

    Please note that the number returned by the deprecated amsCount may differ from the number of events returned by the new ams field due to improvements in our screening and event clustering logic.

    Action Required: Please update your integrations to use the ams field to fetch detailed adverse media events.

    # DEPRECATED
    query GetAmsCount($id: CompanyId!) {
      company(where: {id: $id}) {
        amsCount
      }
    }
    
    # RECOMMENDED
    query GetAmsEvents($id: CompanyId!) {
      company(where: {id: $id}) {
        # Query for the list of events
        ams(pageInfo: {size: 10, offset: 0}) {
          id
          title
          published
          summary
        }
      }
    }

API Changelog: 2025-10-14

This update expands our data coverage by introducing new legal form types for companies registered in Finland. This is a non-breaking change that allows for more precise classification of Finnish entities.

Improvements

  • Added new legal forms for Finland We have added 21 new values to the LegalFormKind enum to support a wider range of company legal forms in Finland. This change enhances our data coverage for Finnish entities, enabling more accurate classification when using the customCompanyCreate and customCompanyUpdate mutations.

    While this is a non-breaking change, we recommend updating any client-side logic that handles LegalFormKind to recognize these new values.

    The new values added are:

    • FI_ASH: Resident-administered area
    • FI_ASY: Right-of-occupancy associationy
    • FI_AYH: Non-profit association
    • FI_ETS: Finnish branch of a European economic interest grouping
    • FI_HY: Mortgage Society
    • FI_KOY: Limited liability joint-stock property company
    • FI_KVJ: Public mutual insurance company
    • FI_OP: Co-operative bank
    • FI_OSK: Housing co-perative
    • FI_OYJ: Public Limited Company
    • FI_SCE: European co-operative society
    • FI_SCP: European co-operative bank
    • FI_SE: European Company
    • FI_SL: Branch of a foreign trader
    • FI_SP: Savings bank
    • FI_TYH: Association for carrying on economic activity
    • FI_UNKNOWN: Unknown
    • FI_VALTLL: State-owned company
    • FI_VOJ: Public limited insurance company
    • FI_VOY: Limited insurance company
    • FI_VY: Insurance association

API Changelog: 2025-10-02

This update introduces new fields to the Company type, providing more detailed information on a company's operational status and employee count. These additions are non-breaking.

New Features

  • Added company status and employee count information We've enriched the Company type with two new fields to provide more context about a business:
    • The new status field returns a ConnectCompanyStatus object, which describes the company's operational status (e.g., "Active", "Dissolved"), the date the status was set, and an isActive boolean flag.
    • The new numberOfEmployees field returns an EmployeeCountInterval object. This provides a from and to integer value, representing the employee count as a range.

API Changelog: 2025-09-29

This update expands our support for German company data by introducing a new legal form. This is a non-breaking change.

Enhancements

  • Added new legal form for German entities We have added a new value, DE_RV, to the LegalFormKind enum. This value represents a "State-conferred Association" (Rechtsfähiger Verein), a type of legal entity in Germany. This change improves our data coverage for German companies.

API Changelog: 2025-09-25

This update introduces enhancements to our review functionality, making it easier to track and retrieve reviews. You can now fetch all reviews for a specific company and see exactly when a review was created. Additionally, it introduces a new way to classify entity identifiers, allowing you to distinguish between primary and secondary identifiers for companies and people. This provides more context and helps in programmatically selecting the most relevant identifier for an entity. There are no breaking changes in this release.

Enhancements

  • Retrieve reviews for a company A new reviews field has been added to the Company type. This allows you to directly query all reviews that have been created for a specific company, returning a list of Review objects.

  • Added creation timestamp to reviews The Review type now includes a createdAt field. This field provides a DateTime timestamp for when the review was generated, which is useful for auditing and sorting purposes.

  • Added kind to EntityIdentifier to classify identifiers We've added a new kind field to the EntityIdentifier type. This field helps categorize an entity's identifiers, making it easier to determine their purpose. The kind field is non-nullable and returns a value from the new EntityIdentifierKind enum:

    • PRIMARY: A primary, official identifier for the entity (e.g., a national organization number).
    • SECONDARY: A secondary identifier for the entity.

    You can now use this field to reliably select the primary identifier for an entity instead of relying on heuristics.

    Example Query:

    query GetCompanyIdentifiers($id: CompanyId!) {
      company(where: { id: $id }) {
        name
        identifiers {
          value
          country
          kind # New field
        }
      }
    }

API Changelog: 2025-09-24

This update introduces a significant new feature for visualizing and analyzing company ownership structures. You can now query the new shareholderGraph field on the Company type to retrieve a graph of its owners, including indirect ownership and beneficial owner information. This is a non-breaking change.

Features

  • Introduced Shareholder Graph for Company Ownership A new shareholderGraph field has been added to the Company type, allowing you to traverse and analyze complex ownership structures.

    The field returns a ShareholderGraph object, which consists of nodes (the entities) and edges (the ownership links).

    • Nodes (ShareholderGraphNode): Represent companies or individuals in the ownership chain. Each node includes the entity's details, their calculated indirectSharePercentage in the root company, and whether they qualify as a isBeneficialOwner.
    • Edges (ShareholderGraphEdge): Represent the direct ownership percentage between two nodes in the graph.
    • To accommodate data from various sources where ownership is expressed as a range (e.g., 25-50%), ownership percentages are now represented by the SharePercentageInterval type, which provides from and to values.
    • You can control the granularity of the graph by using the minimumSharePercentage argument on the shareholderGraph field to filter out smaller shareholders. Refer to the documentation on this parameter to learn more about how it works. Example query:
    query CompanyOwnershipGraph {
      company(where: {id: "company-id"}) {
        name
        shareholderGraph(minimumSharePercentage: 10.0) {
          rootId
          nodes {
            id
            entity {
              name
            }
            isBeneficialOwner
            shareClasses {
              shareClass
              sharePercentage {
                from
                to
              }
            }
            indirectSharePercentage {
              from
              to
            }
          }
          edges {
            parent
            child
            sharePercentage {
              from
              to
            }
          }
        }
      }
    }

## API Changelog: 2025-09-23

Today's update introduces several enhancements to provide more context for Adverse Media Screening (AMS) events. We've also added a new country relationship
type and improved the flexibility of creating and updating custom companies by making the `shareholders` field optional.

### Enhancements

* **Added More Context to Adverse Media Events**
 We've added several new fields to the `AmsEvent` type to give you a clearer understanding of each media article.
   * `eventKind: AmsEventKind!`: Identifies the source of the event. The new `AmsEventKind` enum can be `GEMINI`, `OPOINT`, or `USER_CREATED`.
   * `createdBy: SimpleUser`: Specifies which user created the event, if applicable. This introduces the new `SimpleUser` and `UserAccountKind` types to
     represent user information.
   * `behindPaywall: Boolean!`: A new boolean flag that indicates if the article content is behind a paywall.

* **New `REGISTER` Value for Country Relationship**
 The `CountryRelationship` enum now includes `REGISTER` as a new value.

 For `BusinessPerson`s, person register countries are now classified as Register instead of Address. Residency, nationality, and citizenship data is included
 when available.

 For `Company`, register countries are moved to the new Register kind while other countries are set to Address. These changes are non-breaking but will result
 in country type changes for most entities.

### Improvements

* **`shareholders` Field is Now Optional for Custom Companies**
 The `shareholders` field on the `CustomCompanyCreateInput` and `CustomCompanyUpdateInput` types is no longer a required list. You can now omit this field
 entirely when creating or updating a company that has no shareholders, whereas previously an empty array (`[]`) was required.

## API Changelog: 2025-09

This month's update introduces more structured data for adverse media events and clarifies date ranges for Politically Exposed Person (PEP) roles. We've added
new fields to the `AmsEvent` and `PepRole` types and deprecated their older counterparts to provide a more robust and intuitive API experience. There are no
breaking changes.

### Adverse Media Screening

* **Richer Data for Clustered Media Events**
 The `AmsEvent` type now includes a `clusteredEvents` field, which returns a list of the new `ClusteredEvent` type. Each `ClusteredEvent` object contains an
 `id` and a `url`, providing a more structured way to access articles belonging to the same news cluster.

 The previous `clusteredUrls` field, which returned a simple list of URL strings, is now **deprecated**. Please update your integrations to use the new
 `clusteredEvents` field for more detailed information.

* **New `isCustom` Field on `AmsEvent`**
 A new boolean field, `isCustom`, has been added to the `AmsEvent` type. This field allows you to easily identify whether an adverse media event was added
 manually by a user or discovered automatically by our system.

### Politically Exposed Persons (PEP)

* **Clearer Date Ranges for PEP Roles**
 To better represent the duration of a politically exposed person's role, we have added `startDate` and `endDate` fields to the `PepRole` type.

 The existing `since` field is now **deprecated** in favor of `startDate`. We recommend updating your queries to use these new, more explicit fields.

## API Changelog: 2025-08

This month's update introduces a significant breaking change to how custom company shareholders are managed, splitting them into distinct fields for persons and
companies. We've also added a new, more structured way to query for industry codes on companies and included external source URLs for PEP (Politically Exposed
Person) data to improve traceability.

### Breaking Changes

* **New required shareholder fields for custom companies**
 The `customCompanyCreate` and `customCompanyUpdate` mutations now require you to specify shareholders in two new distinct, non-nullable fields:
 `personShareholders` for individuals and `companyShareholders` for other companies. This change provides a clearer and more structured way to define the
 ownership of a custom company. Any integrations using these mutations must be updated to provide these new fields.

 **Affected Mutations:**
   * `customCompanyCreate(where: CustomCompanyCreateInput!)`
   * `customCompanyUpdate(where: CustomCompanyUpdateInput!)`

 **New Required Fields:**
   * `personShareholders: [BusinessPersonOwnershipInput!]!`
   * `companyShareholders: [CompanyOwnershipInput!]!`

### Features

* **Added structured industry codes for companies**
 You can now query for detailed industry codes on the `Company` type using the new `industriesV2` field. This field returns a list of `ConnectIndustryCode`
 objects, each containing the `code`, its `description`, and the `codeType` (e.g., `SNI_2007`, `SIC_2007`) from the new `IndustryCodeType` enum. This provides
 a more structured alternative to the existing `industries` field, which returns a simple list of strings.

* **Added external source URLs for PEP data**
 To improve data traceability, we've added a new `externalUrls: [String!]!` field to the `PepHit` and `PepRelation` types. This field provides a list of URLs
 pointing to the original sources for the Politically Exposed Person (PEP) information.

* **Added clustered URLs to adverse media events**
 The `AmsEvent` type now includes a `clusteredUrls: [String!]!` field. This returns a list of URLs for articles that have been identified as reporting on the
 same media event, helping you consolidate related news coverage.

## API Changelog: 2025-07

This month's update introduces two major features. You can now create, update, and delete your own custom company and person entities directly via the API. We
have also added a powerful new automated risk calculation feature for companies, providing a detailed breakdown of their computed risk level.

### New Features

* **Manage Custom Company and Person Entities**
 You can now create, update, and delete custom company and person entities that are not available in public registries. This is useful for managing entities in
 jurisdictions we don't cover or for creating special-purpose entities. This functionality is supported by a set of new mutations and their corresponding input
 and payload types.
   * New mutations: `customCompanyCreate`, `customCompanyUpdate`, `customCompanyDelete`, `customPersonCreate`, `customPersonEdit`, `customPersonDelete`.
   * New supporting types: `CustomCompanyCreateInput`, `CustomCompanyUpdateInput`, `CustomPersonCreateInput`, `CustomPersonEditInput`, `CustomCompanyPayload`,
     `CustomPersonPayload`, `ConnectPartialDateInput`, `LegalFormKind`.

* **Automated Risk Calculation for Companies**
 The `Company` type now features a new `automatedRiskLevel` field. This field returns a `RiskCalculationResult` object containing the company's calculated risk
 level, total score, and a detailed breakdown of scores from various risk factors like country, industry, and PEP/sanction screenings.
   * New field: `Company.automatedRiskLevel`.
   * New supporting types: `RiskCalculationResult`, `RiskScoreResult`, `CustomRiskFieldScore`, `RiskLevelSetting`, `RiskLevelKind`.

### Field Additions

* **Added `entityId` to `AmsEvent`**
 The `AmsEvent` type now includes an `entityId` field. This provides a direct reference to the ID of the company or person the adverse media event is
 associated with, simplifying data retrieval and linking events back to their source entity.

## API Changelog: 2025-06

This month's update introduces enhancements to our Adverse Media Screening (AMS) capabilities. We've added a new field to the `AmsEvent` type to provide more
detailed context about the topics detected in media articles, allowing for more precise analysis. These changes are non-breaking.

### Adverse Media Screening

* **Added `topicMentions` to `AmsEvent` for detailed topic analysis**
 We've introduced the `topicMentions` field to the `AmsEvent` type. This field returns a list of the new `AmsTopicMentions` type, which groups specific text
 mentions from an article under their relevant topic. While the existing `topics` field provides a simple list of topic strings, `topicMentions` offers a
 structured way to see exactly which phrases in the text are associated with each identified topic, providing deeper context.

## API Changelog: 2025-05

This month's update introduces a significant refactoring of how adverse media topics are represented, a new mutation for editing business person details, and an
enhancement to sanction filtering. Please note the **breaking change** related to the `AmsEvent` type, which requires an update to any queries fetching topic
data.

### 💥 Breaking Changes

* **Refactored Adverse Media Topics from `topicMentions` to `topics`**
 The field `topicMentions` and its associated type `TopicMention` have been removed from `AmsEvent`. This has been replaced by a simpler `topics` field that
 returns a list of strings. This change simplifies the data structure for easier consumption.

 **Action Required:** Any queries fetching `topicMentions` must be updated to use the new `topics` field.

 *Before:*
 ```graphql
 query GetAmsEventTopics {
   company(where: {id: "..."}) {
     ams {
       topicMentions {
         text
       }
     }
   }
 }

After:

query GetAmsEventTopics {
  company(where: {id: "..."}) {
    ams {
      topics
    }
  }
}

✨ New Features

  • Added Mutation to Edit Business Persons A new editPerson mutation has been added, allowing you to modify the details of a BusinessPerson. This mutation uses the new BusinessPersonEditInput type to specify the person's ID and the fields to be updated (e.g., birthDate), and returns a BusinessPersonPayload.

  • New Filtering Option for Sanctions The SanctionInfo.sanctions field now accepts an optional includeSuggestedFalse argument. When set to true, the query will also return sanctions that have been suggested as false matches but not yet confirmed. The default value is false, so existing integrations are not affected.

📈 Improvements & Fixes

  • Clarified CountryCode Behavior The description for the CountryCode scalar has been updated to clarify that providing an empty string will be handled as a null value.

  • Improved Field Descriptions Documentation for the ams field on BusinessPerson, Company, CustomBusinessPerson, and EntityLike has been standardized and improved for clarity.

API Changelog: 2025-04

This month's update introduces a major enhancement to our Adverse Media Screening (AMS) capabilities. You can now retrieve detailed information about media articles related to an entity, including sentiment analysis and named entity recognition. Additionally, we've improved our PEP screening data by adding aliases to PEP records. All changes are non-breaking.

Adverse Media Screening

  • New ams field for detailed media screening results A new ams field has been added to the EntityLike interface, making it available on Company, BusinessPerson, and CustomBusinessPerson types. This field provides access to detailed adverse media articles and is intended to replace the existing amsCount field, which will be deprecated in a future release.

    The ams field returns a paginated list of AmsEvent objects. Each AmsEvent represents a single news article and contains rich data, including:

    • entityMentions: Specific mentions of people or companies within the text.
    • amsPredictions: Sentiment analysis results (e.g., NEGATIVE, NEUTRAL) with confidence scores.
    • topicMentions: Key topics discussed in the article.

    This change introduces several new supporting types: AmsEvent, AmsEntityMention, AmsPrediction, AmsClassificationKind, TopicMention, NamedEntityKind, TextSpan, and the ISODateTime scalar.

PEP Screening

  • Added aliases to PEP records The PepHit type now includes a new aliases field. This field returns a list of alternative names associated with the Politically Exposed Person, improving the ability to confirm a match.

On this page

API Changelog: 2026-03-25New FeaturesAPI Changelog: 2026-03-24Relationship Data RefinementsAPI Changelog: 2026-03-20New FeaturesAPI Changelog: 2026-03-10ImprovementsAPI Changelog: 2026-03-10Custom Entity ManagementAPI Changelog: 2026-03-09FeaturesAPI Changelog: 2026-03-06FeaturesAPI Changelog: 2026-03-05New FeaturesAPI Changelog: 2026-02-23ImprovementsAPI Changelog: 2026-02-18FeaturesAPI Changelog: 2026-02-13New FeaturesAPI Changelog: 2026-02-12New FeaturesAPI Changelog: 2026-02-11FeaturesAPI Changelog: 2026-02-10FeaturesAPI Changelog: 2026-02-10DocumentsAPI Changelog: 2026-02-09New FeaturesAPI Changelog: 2026-02-06New FeaturesAPI Changelog: 2026-01-19New FeaturesAPI Changelog: 2026-01-16New FeaturesAPI Changelog: 2026-01-14Risk AssessmentAPI Changelog: 2026-01-13AdditionsAPI Changelog: 2026-01-06Enhanced Risk and Review ManagementEntity Portfolio StatusAPI Changelog: 2025-12-19ImprovementsAPI Changelog: 2025-12-19ImprovementsAPI Changelog: 2025-12-17ImprovementsAPI Changelog: 2025-12-17New FeaturesAPI Changelog: 2025-12-16Breaking ChangesNew Features & EnhancementsAPI Changelog: 2025-12-10FeaturesAPI Changelog: 2025-12-09New FeaturesAPI Changelog: 2025-12-08API Changelog: 2025-12-05New FeaturesAPI Changelog: 2025-11-28AdditionsAPI Changelog: 2025-11-27New FeaturesAPI Changelog: 2025-11-05New FeaturesAPI Changelog: 2025-11-03New FeaturesAPI Changelog: 2025-10-29FeaturesAPI Changelog: 2025-10-21ImprovementsAPI Changelog: 2025-10-16Adverse Media ScreeningAPI Changelog: 2025-10-14ImprovementsAPI Changelog: 2025-10-02New FeaturesAPI Changelog: 2025-09-29EnhancementsAPI Changelog: 2025-09-25EnhancementsAPI Changelog: 2025-09-24Features✨ New Features📈 Improvements & FixesAPI Changelog: 2025-04Adverse Media ScreeningPEP Screening