Dev Updates

​

Function custom logs won’t be ingested by default for remote environments

​

🗓️ Timeline

• November 1, 2025: Only warn and error level logs will be ingested for remote environments by default.

​

🧐 Am I impacted?

• If you use custom logs in your syncs and actions with nango.log(...)
• If you rely on viewing debug and info level logs in the Nango UI logs tab for remote environments

​

💡 What should I do?

nango.log('Important information', { level: 'warn' });
nango.log('Critical error occurred', { level: 'error' });

nango.logger({
  level: 'info' // info-level logs and above (warn & error) will be indexed
});

// Now all your regular nango.log() calls will be ingested
nango.log('This will now appear in the UI');

• Options 1 and 2 require changes in your functions’ code and must be deployed using the Nango CLI
• Option 3 can be configured directly in the Nango UI without code changes
• Local development is unaffected - all logs continue to appear when using nango dryrun
• This change helps ensure you’re only billed for logs you actively use in production

​

Why are we making this change?

​

End-user info is no longer shared between connections

​

🗓️ Timeline

• September 8, 2025: End user updates will stop being replicated across connections.

​

🧐 Am I impacted?

• If your users can be tied to multiple organizations
• If you were relying on the end user auto-replication to maintain data freshness

​

💡 What should I do?

• If you are not using them, you can safely ignore this update.
• If you are using them, and wish to keep them in sync (e.g: display name, across connections) you will need to patch each connection when your end user is updated on your side

await nango.patchConnection({
  connectionId,
  provider_config_key
} , {
  end_user: {
    id: '123',
    email: 'new-email@nango.dev'
  }
});

​

Action payload output limit

​

🗓️ Timeline

• October 1, 2025: We will throw an error when an action output exceeds the stated limitation of 2MB.

​

🧐 Am I impacted?

• If you use actions and have a heavy output from the action. Typically the actions that have a large output are fetch-attachment, fetch-call-transcripts and in general any fetching any object from an external system. We have added dedicated proxy code for such operations to help with the migration: fetch-document, fetch-spreadsheet, fetch-file, fetch-database
• If you’re using a now deprecated prebuilt template that fetches objects from an external system

​

💡 What should I do?

• Check your action logs for a warning that you’ve exceeded the action output limitation.
• Verify the actions you’re using and log the output size of the action
• Migrate the action to use the proxy instead

​

Deprecation of /connection endpoints

• All endpoints under /connection are now deprecated. Use the new /connections endpoint instead. They all, except one, take and return the same data. Only the base path has changed.
• The endpoint POST /connections (previously POST /connection) now takes a different body, but returns the same data as previously. This new body is more flexible and ensure stricter typings on your side and validation on our side.
• The endpoint POST /connection/:connectionId/metadata and PATCH /connection/:connectionId/metadata who have been deprecated for a while will not be migrated to /connections and will be removed at the end of the grace period.

​

🗓️ Timeline

• January 20, 2026: All /connection endpoints will be removed.

​

🧐 Am I impacted?

• If you manually use any endpoint under /connection
• If you use the CLI
• If you use the official Nango SDKs

​

💡 What should I do?

• If you use the CLI, you should upgrade to >=0.67.0
• If you use the official Nango SDKs, you should upgrade to >=0.67.0
• If you manually use any endpoint under /connection, you should migrate to /connections
• If you use the POST /connection/:connectionId/metadata or PATCH /connection/:connectionId/metadata endpoints, you should migrate to /connections/metadata
• If you specifically use the POST /connection endpoint to import connections, check the migration section below.

​

Migrating to POST /connections

curl -X POST https://api.nango.dev/v1/connection \
-H "Authorization: Bearer <your-secret-key>" \
-H "Content-Type: application/json" \
-d '{
  "provider_config_key": "slack",
  "access_token": "some-access-token",
  [...]
}'

curl -X POST https://api.nango.dev/v1/connections \
-H "Authorization: Bearer <your-secret-key>" \
-H "Content-Type: application/json" \
-d '{
  "provider_config_key": "slack",
  "credentials": {
    "type": "OAUTH2",
    "access_token": "some-access-token",
    [...]
  }
}'

​

Deprecation of nango.yaml configuration file

​

🗓️ Timeline

• December 1st, 2025: nango.yaml support will be removed.

​

🧐 Am I impacted?

• If you use custom scripts

​

💡 What should I do?

• Follow migration guide -> https://nango.dev/docs/guides/custom-integrations/migrate-to-zero-yaml