Recommended approach

[fresh sparrow]

For production skills that need API keys (Notion, Clay, Slack), are you using SecretRef with secrets.json or a different approach? What's the recommended pattern?

[spice bloom]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[vague herald]

Recommended pattern: yes, use SecretRef for production credentials, but don’t treat secrets.json as the only/primary option.

For skills, the clean path is:

{
  skills: {
    entries: {
      notion: {
        apiKey: { source: "env", provider: "default", id: "NOTION_API_KEY" }
      },
      clay: {
        apiKey: { source: "env", provider: "default", id: "CLAY_API_KEY" }
      }
    }
  }

}

That works when the skill declares metadata.openclaw.primaryEnv; OpenClaw resolves skills.entries.<skill>.apiKey and injects it as that env var for the agent run.

For production, my preference order is:

1. source: "env" if your process manager / container / host secret system already injects env vars.
2. source: "exec" for a real secret manager bridge, e.g. 1Password/Vault/AWS/etc. Good for production if you want OpenClaw to never store the secret value.
3. source: "file" with ~/.openclaw/secrets.json or /etc/openclaw/secrets.json only for single-host/simple deployments, with tight ownership/permissions. It’s supported, but I’d treat it as “local secret file”, not a full production secrets manager.

For Slack specifically, if you mean the built-in channel, use the channel SecretRef fields (channels.slack.botToken, appToken, signingSecret, etc.) rather than a skill-level key.

Docs:
https://docs.openclaw.ai/gateway/secrets
https://docs.openclaw.ai/tools/skills-config