Nango Release Notes

The usage charts on the Billing & usage page can now be broken down by dimension, so you can see what’s driving your usage and costs.

Group by a dimension

Break a chart down to see what makes up the total. For example, group Function runs by Integration to see which integration drives your usage, or group Sync Records by Model to see which models store the most records.

Filter to a single value

Scope a chart to one value, then re-group that slice by another dimension. For example, filter Function runs to a single Connection to isolate one customer’s usage, or filter to failed runs and group by Integration to see which integration’s errors drive volume.

Apply to all

Apply one chart’s group and filter to every chart at once.

Shareable views

The selected month, grouping, and filter are stored in the URL, so you can share or bookmark a link to a specific breakdown.

Claude, Cursor, Codex, or other agents can now build integrations (actions, syncs, webhooks, events) without a local project. This is powered by the new Function Builder skill and REST endpoints for compile, dry run, and deploy functions.

With the Nango skill, your agent turns behavior described in a prompt into a complete integration: it generates TypeScript code, compiles it, tests it against a real connection, and deploys it.

You can also pair the skill with an agent inside your product to generate integrations on demand when your customer prompts it. This is also called just-in-time integrations.

We are migrating all sync executions to our serverless AWS Lambda runtime, and introducing a 10-minute execution limit per run. This gives us better autoscaling, more predictable execution isolation, and a simpler runtime model across Nango Cloud environments. Lambda has a hard timeout, so long-running syncs must checkpoint work and continue across runs instead of relying on a single long execution.

Timeline

• Now: All action and webhook function executions have already been migrated. We are now migrating all sync executions for accounts without long running syncs.
• Next 3-6 months: We will progressively migrate accounts with long-running syncs by assisting with migration to checkpoints. We will announce milestones in this changelog and coordinate directly with impacted accounts.

Am I impacted?

• All accounts using syncs without checkpoints are impacted and should migrate to checkpoint-based progress. Short running syncs will still continue working without issue after migrating to lambdas, but it is still recommended to implement checkpoints.
• We will be reaching out directly to affected accounts to assist in the migration.

What to do

• Migrate all syncs to use checkpoints using the migration guide and associated skill

If you do not want to migrate yet or cannot migrate within the timeline, please reach out and we will find a workable path with you.

We replaced environment secret keys with API keys. Previously, every environment had a single secret key with full access to all endpoints. You can now issue multiple keys and grant only the scopes each use case requires.

Key details

• Scoped permissions: Choose Full access or Custom scopes when creating a key. Limit keys to specific operations like deploys, reading connections, or triggering actions.
• Safe rotation: Create a replacement key, swap it into your service, watch the Last used column to confirm the old key is no longer in use, then delete it.
• RBAC-aware: Support role members can only see the last four digits and scopes for troubleshooting, but cannot reveal key values.
• No migration required: Your existing secret keys continue to work as API keys without any changes.

Each endpoint in the API reference now lists the scopes it requires. See the API keys documentation for the full scope list and advised profiles.

We added a Playground to the Nango dashboard. You can now trigger actions and syncs directly from the Nango dashboard. Pick an integration, connection, and function, fill in the inputs, and hit Run!

• Enabled functions only: The function dropdown shows only functions that are enabled for the selected integration.
• Input validation: Required fields are validated before execution. Missing inputs are flagged immediately without triggering a run.
• Inline results and errors: Execution results, timing, and error codes (e.g., invalid credentials) are displayed directly in the panel.
• Jump to logs: Navigate to the filtered logs view for any execution directly from the result.
• Permission-gated: Playground access in production environments respects your team’s roles.

We added role-based access control to the Nango dashboard. You can now assign one of three roles when inviting team members:

• Full Access: Unrestricted access across all environments. Manages account settings, billing, and team.
• Support: Read-only production access without sensitive credentials. Full access in non-production.
• Contributor: Non-production environments only. No production access.

Key details

• Production flag: Mark any environment as production in Environment Settings > General. Once set, Support members get read-only access and Contributors lose access entirely.
• API access is unaffected: Roles apply to dashboard access only. Any caller with a valid secret key retains full API access.

Available on the Growth and Enterprise plans. See the Team & roles documentation.

Effective April 16, 2026

Running nango compile or nango deploy currently generates three files under .nango/: schema.ts, schema.json, and nango.json. We will stop generating schema.ts and schema.json. The nango.json file remains unchanged.

Am I impacted?

• If you import TypeScript types from .nango/schema.ts in your application code (e.g., to type SDK calls like nango.listRecords(...)).
• If you consume .nango/schema.json for runtime data validation or code generation.

Migrating off schema.ts:

• Export the types directly from your sync/action files using z.infer, then import them in your application code.

Migrating off schema.json:

• JSON schemas are now available per sync/action inside .nango/nango.json via the json_schema property. This replaces the top-level schema.json, which had naming conflicts when models across integrations shared the same name.
• To generate JSON Schema programmatically, Zod v4 supports this natively with z.toJSONSchema().

See the data validation guide for more details on working with Zod schemas in Nango.

We introduced customizable Sync checkpoints to make syncs interruptible and resumable.

Previously, a failed sync would restart from the beginning of its execution cycle, potentially wasting time processing data that had already been synced. You can now set a checkpoint field with a custom comparison object and use nango.getCheckpoint() and nango.saveCheckpoint() directly in your function code to track progress at a granular level.

Checkpoints are optional; not using them implies the function will always run from scratch. See the Sync checkpoints documentation.

No breaking changes: Existing syncs without a checkpoint declaration continue to run as full syncs. For any sync with a large or growing dataset, define a checkpoint schema and call saveCheckpoint() after each batch.

Migration Note: Checkpoints are a more flexible replacement for nango.lastSyncDate. We also removed the concepts of incremental vs. full syncs from the function signature. If you use nango.lastSyncDate for incremental syncing, we recommend migrating — checkpoints are more resilient, more flexible, and will be the primary supported path going forward. There is no deprecation timeline for nango.lastSyncDate, but new improvements will only land on checkpoints. Follow the Migration guide.

Retention lifecycle

1. Automated payload pruning. If a record has not been updated for 30 days, Nango automatically prunes its payload. The record still exists and its metadata remains intact, including record ID, sync state, and payload hash (used for change detection). After pruning, the record’s data fields are no longer retrievable from the Nango cache, but Nango can still track the record and detect future changes. This pruning does not impact sync execution or delta-detection.
2. Automated hard deletion. If a sync has not executed for 60 days, records belonging to that sync will be permanently deleted (payload and metadata).

Timeline

Policies start on January 8, 2026. Record payload pruning starts 30 days later. Record hard deletion for inactive syncs starts 60 days later.

Am I impacted?

Most customers (including most sync users) are not impacted, in particular if you use syncs for replication, receive updates via Nango webhooks, and replicate records into your own system shortly after they arrive in the Nango cache. You are impacted if you use Nango sync’s cache as a long-term persistent data store, reading or editing record payloads from the Nango cache long after they were updated.

What to do

If you fetch record payloads from Nango long after they were updated (30+ days), reach out. We will make sure you do not experience breaking changes.

Why

These retention policies are part of our broader commitment to helping customers meet modern data compliance and security expectations. They ensure that sensitive user data is not stored indefinitely in the Nango sync cache when it is no longer needed for syncing.

See the Records cache documentation.

We also introduced a new endpoint to manually prune records.

You can use PATCH /records/prune to empty record payloads on demand while preserving the metadata. See the Prune records API reference.