A few weeks ago I posted a question here: **How do you handle API credentials in n8n workflows you share with teammates?**
Got some useful responses, and also spent time experimenting. Here’s what I actually ended up building — sharing because it might save someone else the same debugging spiral.
-–
**The core problem I kept hitting**
The pattern I see most often (and used myself):
1. HTTP Request node fetches tenant_access_token from Lark
2. Pass token as header into next node
3. Token now lives in execution logs, node outputs, and the exported JSON
The issue is not just hardcoding. Even the fetch-then-use pattern exposes credentials. Once you look at execution logs or hand the JSON to a teammate for debugging, the token is sitting there in plain text.
This is what pushed me toward thinking about it differently: it is not really a secret storage problem, it is an execution boundary problem.
The goal I set: n8n should never see raw credentials at any point — not in inputs, not in outputs, not in logs.
-–
**What I built: a proxy layer between n8n and the APIs**
n8n sends requests to the proxy using a single rotating proxy token. The proxy holds the actual Lark credentials, handles tenant_access_token refresh automatically, and forwards the request. Even if someone dumps execution logs, there is nothing sensitive in there.
Disclosure: the proxy layer I am using is NyxID, built by my team. Take that into account — the architectural pattern works regardless of which tool you use to implement it.
-–
**Concrete setup: Lark approval to n8n to downstream actions**
My specific workflow is an HR approval chain:
1. Approver clicks approve/reject in Lark
2. Lark sends webhook to n8n
3. n8n routes based on approval status
4. All downstream Lark API calls go through the proxy
The proxy token goes in n8n native credential store — if that gets exported, it is a rotating token that can be invalidated instantly, not the actual Lark secret.
-–
**What this actually solved**
- Workflow JSON is now fully shareable — no credential exposure
- Lark token expiry handled automatically — no more mid-workflow failures at the 2-hour mark
- One place to rotate credentials
- Audit trail — all Lark API calls go through one layer
-–
**What it does not solve**
Moving to a proxy shifts the trust boundary, it does not eliminate it. You still need: proxy auth, logging policy, rate limiting, replay protection.
-–
Happy to share the n8n workflow structure in the comments. Curious whether others here have hit the Lark token expiry issue — it seems to catch everyone eventually.