+1 on Benjamin’s point that n8n’s REST API doesn’t expose credential CRUD — real gap if you need to automate rotation for a compliance window.
Two things worth adding:
1. STS AssumeRole works for AWS but doesn’t generalize. The moment you add a non-AWS key (Stripe, OpenAI, SendGrid, anything), you’re back to manual UI clicks. If rotation is a SOC2/ISO control, auditors want one answer for every credential type, not AWS-only.
2. The cleanest pattern we’ve found is keeping credentials *outside* n8n — n8n’s HTTP node points at a gateway, the gateway injects the right auth header server-side. Rotation becomes one API call on the gateway, and every workflow (n8n, Claude Code, Cursor…) picks it up immediately.
We’ve been building NyxID as an open-source take on that pattern — credential injection + reverse proxy + optional REST→MCP wrapping. Happy to share how the rotation flow looks: github.com/ChronoAIProject/NyxID
For the short term, STS + a Lambda on EventBridge is the right stopgap if you only need AWS rotation.
welcome to the n8n community @Vignesh_Balasubraman
I’d add that this is probably a good case for an official feature request with the security/compliance use case clearly described. The key detail is not just “API for credentials”, but support for audited secret rotation on n8n Cloud, including permissions, logs, and safe production controls. That may help the n8n team evaluate it differently than a generic credential CRUD request.
docs for help
n8n public REST API Documentation and Guides | n8n Docs
External secrets | n8n Docs
Credentials environment variables | n8n Docs
@Vignesh_Balasubraman skip stored creds entirely — call STS AssumeRole from a Code node and feed the temp tokens straight into an HTTP Request node, n8n never holds long-lived keys that way
set AWS_KEY and AWS_SECRET as env vars on your instance (not n8n credentials), swap the role ARN for yours, and the Code node mints fresh 15-min tokens every run so nothing long-lived sits in n8n’s credential store