Hi SriLakshmi,

In short, this is a Mendix platform change. It does not affect your application’s own REST or SOAP services, and it is not related to your Git migration or the version upgrade. Please find the details for each point below.

What are these APIs used for?

These are Mendix platform APIs used to automate Mendix Cloud tasks from outside Studio Pro:

• Build API – creates deployment packages (.mda) from your repository
• Deploy API (v1 and v2) – manages environments, for example starting and stopping apps and deploying packages to Test, Acceptance or Production
• Backups API (v2) – creates, downloads and restores environment backups

They are mainly used in CI/CD pipelines (such as Jenkins, Azure DevOps or GitHub Actions) and in custom scripts.

Does this affect application-level REST, SOAP, published services or integrations?

No. Only calls to the APIs listed above that authenticate with an API key are affected. Your published REST, SOAP and OData services and your consumed integrations use the authentication configured within your application, and they will continue to work as they do today.

Will any existing integrations stop working?

Only scripts or pipelines that call these Mendix APIs using the “Mendix-Username” and “Mendix-ApiKey” headers. From January 1, 2027, those calls will no longer be accepted. Nothing else is affected.

Is this related to the SVN-to-Git migration or the upgrade to 9.24.44?

No. The change applies to all Mendix Cloud users, regardless of the Mendix version or version control system. The timing is a coincidence.

As a side note, if you have a pipeline that uses the Build API, please make sure it now uses your Git branch name and commit ID instead of the old SVN revision numbers.

How can you verify whether you are using these APIs?

• Search your CI/CD pipelines, scripts and configuration files for “Mendix-ApiKey”, “Mendix-Username” or “deploy.mendix.com”.
• In the Mendix Portal, check your user settings for existing API keys, and ask your team members to do the same. An existing key may be in use somewhere.
• In Studio Pro, use Find (Ctrl+F) to search for “deploy.mendix.com”, in case a microflow calls these APIs directly.

If nothing is found, no action is required.

How to migrate to a Personal Access Token (PAT)

• In the Mendix Portal, open your user settings, go to Developer Settings, and create a Personal Access Token with the required scopes (for example mx:deployment:read, mx:deployment:write, mx:build:read and mx:build:write).
• In your scripts, remove the “Mendix-Username” and “Mendix-ApiKey” headers.
• Add the following header instead: Authorization: MxToken <your-PAT>
• Run the pipeline once to confirm that everything works as expected.

Documentation: https://docs.mendix.com/apidocs-mxsdk/apidocs/deploy-api

I hope this clarifies the situation. If it helps, please mark it as the accepted answer.

Hi Sai,

The important distinction is that this deprecation applies to authentication for the specified Mendix Platform APIs, not to all REST APIs used by your Mendix application.

1. What are these APIs used for?

• Deploy API v1/v2: Automating environment management, uploading deployment packages, and deploying applications.
• Build API: Automating deployment-package creation and related build operations.
• Backups API v2: Automating backup snapshots, archive creation, and restore operations.

2. Does this affect application-level REST APIs?

Not directly. REST services exposed by your Mendix application and REST APIs consumed by your application are separate from these platform-management APIs. They are not automatically affected by this particular deprecation.

However, any external script or integration using one of the specifically listed Mendix Platform APIs with an API key must be reviewed.

3. Will existing integrations stop working?

Integrations that continue relying on the deprecated API-key authentication may fail once support ends. Migrate the affected integrations to Personal Access Tokens (PATs) before the announced deadline, January 1, 2027.

Create a PAT with the appropriate API scopes and permissions, update the authentication configuration in your scripts or CI/CD tools, and test the complete workflow before retiring the old credentials.

4. Is this related to the SVN-to-Git migration or the Mendix version upgrade?

Not inherently. The repository migration and the Studio Pro upgrade are separate from the authentication change. The migration may be a useful opportunity to review your automation, but it does not itself cause this API-key deprecation.

5. How can you identify whether your application is affected?

Review your CI/CD pipelines, PowerShell or shell scripts, scheduled jobs, custom automation, and backup/deployment tooling. Search for API requests using headers such as Mendix-ApiKey and identify whether they call any of the affected APIs.

For each affected integration:

• Generate a PAT with the minimum required scopes.
• Replace the API-key authentication with the PAT authentication required by the specific API.
• Store the token securely in your CI/CD secret store or environment configuration.
• Test build, deployment, and backup/restore operations as applicable.

Official references:

• Mendix API Documentation
• Deploy API v1
• Deploy API v2
• Backups API v2

Hope this clarifies the scope and migration approach!

We are using a licensed Mendix Cloud application and deploy through the Mendix Portal.

We recently migrated from SVN to Git and upgraded from 9.24.26 to 9.24.44. We noticed the API key deprecation announcement. How can we determine whether our application is using Deploy API v1, Deploy API v2, Build API, or Backups API v2?

We mainly use Mendix Cloud.

Would this announcement affect us in any way?