This has been one of our most requested features, and it’s finally here: you can now replace assets in your DatoCMS project while keeping the original URL.

When replacing an asset, you now have two options:

• Create new URL (existing behavior): The new asset is available immediately, but with a fresh URL. The old URL will be purged from cache and will disappear after complete propagation. Use this when you need immediate availability of the new file.

• Keep the original URL (new!): Existing links will continue to work automatically, but changes may take 5-10 minutes to appear everywhere due to CDN and browser cache propagation. Some users may temporarily see the old version. Use this when you have many existing references and want to avoid updating URLs.

Limitations

Assets can only be replaced keeping the original URL if:

• The new asset has the same file format as the original (for example, JPEG → JPEG).

• You are using DatoCMS’s default asset manager. This feature is not supported when using custom Enterprise asset storage (S3/GCP).

For full details on the related API changes, see the CMA documentation.

We're changing the default behavior when you list all records in the Content Management API to better reflect modern content workflows. The default version parameter will change from published to current, giving you access to the latest version of your content by default.

What's changing

When you list all records without explicitly specifying a version parameter:

• Previously: The endpoint returned only published records (version: "published").

• Now: The endpoint will return the latest available version of each record (version: "current"), which may include drafts, updated content, or published records.

Who is affected by this change?

This change will apply to all brand new DatoCMS projects created from today onwards. If you have an existing project that you'd like to update, you can manually opt-in to this behavior in the Environment Settings.

Please note that this change cannot be undone, so we strongly recommend testing the effects in a sandbox environment before applying the change to your primary environment.

Existing projects that do not opt-in will maintain the current default behavior (published).

Why we're making this change

This new default aligns better with common use cases:

• API consistency: When you retrieve a record, it already returns the latest version by default (current). This change makes listing all records behave consistently with retrieving a single record.

• Developer expectations: This matches the behavior developers typically expect when fetching content programmatically.

What you need to do

For new projects created from today onwards: If you want to receive only published content instead of the latest version, simply add the version parameter explicitly:

const records = await client.items.list({
  version: "published", // Explicitly request only published records
  filter: {
    type: "blog_post"
  }
});

For existing projects: Your project will continue to use the current default (published) unless you manually opt-in to the new behavior via Environment Settings. We recommend testing the change in a sandbox environment first.

More information

For complete details on the version parameter and how to filter by publication status, see our List all records documentation.
If you have questions or concerns about this change, please reach out to our support team.

Its now easier to understand the usage of API tokens associated with your project.

We've made their "Last Used Time" visible across your project settings, making it helpful for projects with many tokens to see each one's activity on the CMA and CDA.

If a token was last used months ago, its probably safe to get rid of them.

To see tokens and their usage, head over to Project Settings > API Tokens and select the token you want to see the associated activity for.

We've just rolled out a significant improvement to the plugin scope: as of today, plugin settings are synced across multiple users in real time, just as we do for records and other entities.

What's new

Until today, plugin data were loaded into DatoCMS at a few predefined moments: when opening the CMS, after installing a new plugin, and... that was pretty much it. That caused issues in some non-trivial cases involving plugins with complex parameters: if multiple users updated a plugin's settings at the same time, they risked overwriting each other's changes.

We solved the problem with the same approach with many other entities of DatoCMS: now the changes to plugin parameters are propagated to other users instantly, so that they always see the last version of it.

You can now run any DatoCMS API method straight from our CLI with the new cma:call command. No need to write custom scripts anymore, just call the method you need directly from your terminal.

The command dynamically discovers all available resources and methods from @datocms/cma-client, so you're always working with the latest API surface.

Key features:

• Dynamic discovery: All resources and methods are automatically available

• Smart validation: Validates request body requirements and prompts for --data when needed

• Flexible parameters: Supports URL placeholders via positional arguments and query parameters via --params

• Helpful errors: Clear error messages with suggestions when something goes wrong

Perfect for quick API calls, testing, automation scripts, or when you just need to run a one-off command without spinning up a full script!

We've just rolled major changes to the Site Search feature: settings for how to index websites now have a dedicated section in the Project settings, while build triggers have become leaner.

What's new

Until today, Site Search was buried deep within build triggers and tightly integrated with the build system: you could crawl a website only if you had a build trigger.

That wasn't always what you needed. Maybe on a non-static website, there's no build phase at all, but you rightly want to leverage the Site Search functions.

So we improved it to bring about a few major changes:

• Site Search is now independent of Build Triggers being used. to benefit from Site Search, you simply have to create a Search Index, and you're good to go. No more artificial coupling.

• Site Search logs split apart from Build Triggers logs. Build triggers and indexing logs are now two different sections in your Project settings.

• Independent control over indexing.  You can control when and how your sites are indexed for search purposes independently of their build process (even if you don't have one).

ℹ️ If you had Site Search enabled, your setup has been migrated to the new configuration: for each build trigger with indexing enabled, we created a search index and linked it to the build trigger.

How does it work?

Navigate to the Search Indexes section in Project settings to create or manage your search indexes:

Why the change? 

Decoupling search indexes from build triggers gives customers explicit control over when indexing happens and provides independent failure reporting and logging for indexing.

Plus, it opens up new possibilities: you can now add a custom suffix to the user-agent we use when crawling websites. With that, you can work on your robots.txt and sitemaps to get different search indexes for various sections of your website (for example, one for the blog, another for the documentation, and another for the FAQs).

We've just rolled out Smart Confirmation Guardrails to prevent accidental data loss while keeping your workflow smooth and efficient.

What's New?

Destructive actions now show clear consequences before you commit. No more "oops" moments.

In primary environments, high-risk changes affecting 10+ records require explicit confirmation by typing what you're destroying (e.g., "delete author_name field in 2k+ records"), while smaller changes use lighter confirmations to keep your workflow fast. Sandboxes remain unrestricted for rapid iteration.

How Does It Work?

When you attempt a destructive action in your primary environment, the system calculates potential impact.

If 10+ records will be affected, it shows a detailed confirmation dialog with exactly what will be deleted or modified, how many records will be impacted, and a confirmation phrase to type that reinforces the consequences.

If fewer than 10 records will be affected, a simpler dialog will be shown that doesn't require a confirmation phrase.

Why Does It Matter?

Accidentally deleting a model, converting a field type, or removing a locale can cause massive data loss, broken references, and hours of recovery work. These guardrails give you safety without friction — protection appears exactly when and where you need it most.

This is especially valuable for:

• Enterprise teams managing large-scale content operations with thousands of records

• Multi-locale projects where removing a language could affect hundreds of assets and records

• Complex schemas with interconnected models and references

You get enterprise-ready protection with smart defaults: your production environment stays safe, while development environments stay fast.

We've added a new path filter for uploads in the GraphQL API (CDA), allowing you to filter uploads based on their storage path.

The filter supports exact matching (eq), negation (neq), inclusion (in), and exclusion (notIn) operations. All path comparisons are case-insensitive.

1
{
2
  # Find a specific asset by path
3
  upload(filter: { path: { eq: "/123/1763384420-hero-image.jpg" } }) {
4
    id
5
    url
6
  }
7

8
  # Find multiple assets by paths
9
  allUploads(filter: { path: { in: ["/123/1763382120-logo.png", "/123/1763381111-banner.jpg"] } }) {
10
    id
11
    url
12
  }
13

14
  # Exclude specific paths
15
  allUploads(filter: { path: { notIn: ["/123/1763383331-preview.jpg"] } }) {
16
    id
17
    url
18
  }
19
}

You can also use this new filter when fetching uploads via the CMA or in your project Media Area

We're adding a new way to let users access the CDA Playground without requiring "Create/edit API tokens" permissions in their role.

This is especially useful for developers — including external contractors — who have been given an API token by someone else, and need to explore and test content queries but don't require full API token management capabilities.

What's New

For people with no permission to "Create/edit API tokens", we've added a "Force CDA playground visibility" toggle in the Editor preferences. When enabled, users can access the CDA Playground regardless of their role permissions.

How It Works

For users with this toggle enabled, the CDA Playground will prompt for an API token on first access.

Once a valid token is provided, the playground functions normally — the toolbar displays the custom token and allows updating it as needed.

This gives developers and technical users the access they need to work with the Content Delivery API, without granting broader API token management permissions.

We're introducing favorite locales to keep your workspace focused and your most-used languages instantly accessible.

What's New?

Mark up to 6 locales as favorites to prioritize them across the CMS, reducing clutter and eliminating the need to hunt through long language lists.

• Instant access: Favorite locales appear at the top of selectors throughout the CMS — no more hunting through lists.

• Cleaner workspace: While editing records, collapse non-favorite locales to keep your view focused on what matters.

How Does It Work?

Open Editor's Preferences from your avatar menu (upper right corner), enable "Favorite Locales," and select your most-used languages. You can choose up to 6 favorite locales.

Why Does It Matter?

Managing 10, 15, or 20+ locales means constant scrolling and visual noise. By surfacing only the languages you use regularly, this feature eliminates friction in your daily workflow — especially valuable when you work primarily in a consistent subset of locales. You get faster navigation and a cleaner interface without changing how localization works.