RSSChangelog

We're adding a new billing model to the OpenSanctions API: prepaid credit bundles, which you buy in the customer portal. Existing customers stay on their current billing unless explicitly migrated. To move over sooner, contact the support team. Your API key, endpoints and integration stay the same after migrating, so there is no code to change. Larger bundles cost less per screening query: you pay less by committing to more, there is no usage bill at the end of the month. In effect, you can manage your API spend precisely. The on-premise API (yente) is not affected. Credit bundles will eventually be the default way for new customers to use the OpenSanctions API.

Prices exclude applicable tax. Credits are valid for one year from purchase. Only /match and /search consume credits: each query in a /match request uses one credit, so a batch of 100 queries uses 100 credits, and each /search request uses one credit. Calls to /entities and /statements remain free. You receive an email when you have used 50% and 80% of a bundle, so you can keep track of consumption. If you want screening to continue without interruption, turn on auto-recharge in the portal: a new bundle of the size you choose is then bought automatically when your balance runs low.

For more on how requests are metered, see the API FAQ.

Please check that your configuration supports HTTP status 307 redirects for HTTP requests to data.opensanctions.org. Starting in August, the site may redirect users attempting to fetch a specific data export to an updated location.

The canonical location will now be at /artifacts/<dataset>/<version>/, where previously a mix of datasets/latest/<dataset> and /datasets/YYYYMMDD/<dataset> were used.

The goal of this change is provide immutable locations for each data export, helping to more clearly identify versions of the dataset.

The statement-level API available at the /statements endpoint currently includes metadata statements, identified by the id property name. These statements are not part of the data payload but rather entity checksums used internally by OpenSanctions for change detection. As they have caused some confusion, we have recently removed them from the statements.csv data export, and will now do the same for the API.

In Q4 2025, stretching into Q1 2026, we will be migrating our billing system for both API and bulk data customers from Chargebee to Stripe. This will reduce the number of moving parts in our service, as we already use Stripe to collect all credit card payments.

We hope that this change will pass unnoticed for our customers. Please bear with us if you do notice any minor hiccups during this time. In particular, customers may receive a partial service invoice for SaaS usage. Our highest priority during this migration is to never overcharge any of our customers. As always, if something doesn't look or feel right, please get in touch with our support team.

After releasing the new logic-v2 result scoring algorithm in September, we're planning to make it the default used by the OpenSanctions API service when no other algorithm is specified (or the best algorithm is selected). API users can prepare for this change in two ways:

• Adopt logic-v2. The new system significantly reduces false positive alert rates and improves match quality. We also plan to make this new algorithm the focus of future feature enhancements and precision improvements.
• Specify algorithm=logic-v1 as part of your query string to opt out of this change. This will freeze the use of logic-v1, the current best/default algorithm. This option is recommended for API users where scoring changes may require a regulatory approval/notification. We may choose to fully retire logic-v1 within the next 24 months.

Please feel free to reach out to the support team with any questions regarding the new scoring algorithm.

Suspended: After receiving feedback from our customers, we have decided to reverse this decision. The cutoff parameter has been marked as deprecated, but will remain in place indefinitely. The announcement below is only retained for reference. It will not be implemented.

In an effort to simplify our Matching API, we are removing the cutoff parameter. Once this change becomes effective, only matches, i.e. those results scoring higher than threshold will be returned. If you care about low-scoring results being returned, please adjust the threshold parameter instead. The match property on the returned results will remain and function as before, and match will be set to true for all results once this change becomes effective.

We are planning an upgrade to the technology stack powering the OpenSanctions API in the coming days. While new functionality will be described in a separate announcement, users of the system might notice small changes in matching results. They can be a result of:

• Improved company type suffix/prefix matching (LLC, OAO, OJSC, etc.).
• More precise retrieval of matching candidates with very generic names (A B C Limited), and of names across different scripts (Putin and بوتين).
• Fix of a bug in logic-v1 in which certain match scores for organizations could vary between requests.
• Implicit support for a broader range of jurisdictions (eg. Alberta is recognized as Canada).

Of course, it is our goal to keep matching results stable over time. The result of rolling out these improvements to some of the existing matching systems, however, should strictly improve precision and reduce false positive burden for existing users.

Effective December 31, 2025, the secondary KYB data API at api.graph.opensanctions.org will be shut down and no longer supported.

We’ve made this decision to focus on improving and expanding the core OpenSanctions dataset and API. If you are using the KYB/Graph API, please plan to transition before the end of the year. We encourage you to reach out if the impact of this change is severe for your business.

We have begun a two-step migration in the /match API response format that affects users relying on the features and matcher fields.

1. The matcher field in /match responses will be removed after February 27, 2026. Equivalent information is available via the /algorithms route (free to use).

2. A new explanations field has been added that is a strict superset of features. In addition to the partial scores produced by each component of the matching system, it includes textual descriptions of the matching decisions from each of these subsystems. These descriptions are designed for display in analyst workbenches or can be passed to generative AI tools to help interpret screening alerts. The features field will be removed after February 27, 2026. Users should update their applications to consume explanations before this date.

Due to excessive bandwidth use, we are planning to limit access to historical data exports of our sanctions data (pre-2024). Bulk data customers and non-commercial users can request authenticated access by contacting our support team.

The following URL paths will become access-controlled:

• https://data.opensanctions.org/datasets/2021*
• https://data.opensanctions.org/datasets/2022*
• https://data.opensanctions.org/datasets/2023*
• https://data.opensanctions.org/graph/*

We kindly ask all users that retrieve bulk data extracts from data.opensanctions.org to ensure that the HTTP clients used to fetch bulk files are configured to support redirect response codes such as HTTP 302 (Found), 303 (See other), and 307 (Temporary Redirect).

Background: as our archive grows, we may need to virtualize some of our content delivery, or put in place redirects for deprecated locations within the data archive.

A new version of the API will remove the regression-v2 scoring algorithm, but leave regression-v1 in place for now. regression-v2 is a historic scoring method that is discouraged for screening use (it's intended use is internal de-duplication of entities in our database).

A new regression-v3 scoring mechanism is now being developed and will be released, but not recommended for screening use. Any requests that are sent to the API using regression-v2 will be re-written to use regression-v3 in the future.

This release updates various dependencies, introducing new fields in the followthemoney schema and bringing in security patches for the web stack dependencies.

We're also implementing the Reconciliation API's Data Extension protocol for the first time, allowing users to enrich OpenRefine tables with new columns using the API.

See more: https://github.com/opensanctions/yente/releases/tag/v4.2.0

This change is relevant for users of the index.json and catalog.json metadata. API and yente users as well as those users who download static files based on location are not affected.

As the number of datasets in the default collections grows, the metadata size is becoming a factor: the main index file is now larger than two megabytes. In order to prevent scaling issues in the future, we're splitting up the dataset metadata into two files: index.json and statistics.json. index.json will contain fewer summary facts about each dataset. The extended statistics (e.g. the number of entities in the dataset linked to each country) will be in the more in-depth statistics.json.

The following fields will be removed from dataset metadata:

• schemata
• properties
• targets (and all nested items)
• things (and all nested items)

These fields continue to be published in a statistics.json file. A statistics.json file is published with each data export of a dataset, and referenced from the index.json via the statistics_url field.

Additionally, the following fields will be removed in favor of replacements that are already in index.json:

• sources - use datasets instead
• externals - use datasets instead