Does n8n let you share credentials with your team?

Yes. n8n documents credential sharing within projects or with specific users, so a team can use one stored credential instead of each person holding a copy. Personal credentials can also be used inside a team project without being shared directly.

Can I list all n8n credentials through the API?

The n8n API documentation says credential listing is available only to the instance owner and admins, and the response does not include the credential secrets. That is enough for an inventory, not enough to read keys.

Should we clean up our n8n setup or rebuild it?

Count the workflows with no named owner. If that is more than half, rebuilding the few you actually need is usually cheaper than documenting the rest, because documentation of an unowned workflow still leaves nobody accountable for it.

n8n credential audit: find the owner of every workflow

The pattern shows up in operator forums every few months: an instance that began with one workflow now carries a pile of API credentials and paid subscriptions nobody can match to a workflow. I have not seen that instance, and the counts in those posts are unverified, so treat this as a report, not a measurement. The shape is still right: ownership.

What the sprawl actually costs

The real cost is not the subscriptions, it is that nobody can change anything safely.

Three facts go missing at once: who created each workflow, who can see its credential, and who can switch it off. n8n's documentation treats these as separate concerns. Credentials are stored authentication details, sharing happens per project or per user, and the workflow sharing model separates the creator from other editors. If your team never used those distinctions, the instance has no owners, only history.

I have worked this problem from the outside, on a multi-site stack of 25 GoHighLevel locations. The hard part was never the connector, it was establishing which automation could write and who to ask. That is most of what a business pays for when it bolts n8n onto the CRM it already has.

How to run an n8n credential audit

Four passes, about two hours total. These come from the documentation, not a run on your instance.

List the credentials (about 20 minutes). Export from the interface, or use the public API: credential listing is available to the instance owner and admins, and the response excludes secrets. One row per credential, with the service it points at.
Map workflows to people (about 30 minutes). For each workflow, write down the creator and everyone who can edit it. n8n keeps that distinction; your sheet should too.
Pick a sharing model (about 25 minutes). Credentials shared into a project give a team access without copies, and personal credentials can be used inside a team project without being handed over. The pricing page lists an encrypted credential store and credential sharing as included, with end-user credentials for Enterprise.
Fill in the verdict column (about 25 minutes). Use the table below. Nothing gets deleted in this pass; the output is a list of decisions.

The ownership table

Named owner	Fired in last 30 days	Paid seat or subscription	Verdict
yes	yes	yes	keep, put the owner's name in the workflow title
yes	no	yes	ask the owner, then cancel or re-enable
no	yes	yes	assign an owner this week, it is running blind
no	no	any	retire the workflow, revoke the credential

Add one column by hand: what breaks if this stops. If nobody can answer that in a sentence, the workflow is not in production, it is just switched on.

Is it cheaper to clean up or rebuild

Run the arithmetic on your own inputs, not a benchmark. Take S, your paid subscriptions, and C, the average monthly cost of one. S times C is the monthly line. Count U, the ones no workflow called in 30 days. U times C is the recurring saving, repeating monthly whether or not you touch the workflows.

Then count N, the workflows with no named owner. My opinion, not a measurement: if N is more than half the total, rebuilding the handful you actually need usually costs less than documenting the rest. That is the same call as fix or rebuild on a neglected account.

Limitations

The counts in the original forum reports are unverified. Nothing here depends on them.
An audit tells you who owns a credential, not whether its scope is too wide. That check happens at the provider end.
API and sharing behaviour depends on your plan and role; confirm against your own instance first.
The table decays unless one person owns the table. Review it monthly.
Knowing who owns a workflow is not knowing what it did. For that you want a record of every run, the case for auditing what your agent actually did.

My take

Two hours and one table beat another workflow. The instance is not broken, it is unowned, and unowned systems get expensive quietly. Run the credential list this week, name an owner for every row, and keep containment first, the way I would before an agent touches your CRM.