Your API Key Shouldn't Show Up in Your Logs

A token goes into a webhook request like any other field. A week later, someone's digging through logs for a totally different bug, and there it is: a plaintext API key, just sitting in the input trace.

Nobody did that on purpose. It's just what happens when a secret and a regular input get treated the same way.

The actual problem

A webhook call to trigger a workflow usually looks like any other POST request: a JSON body with whatever inputs the process needs. If one of those inputs happens to be a credential or an access token, it rides along in the same body as everything else, and by default, everything in that body can end up visible in logs, process summaries, or API responses. None of that's malicious. It's just what "log the input" means if nothing tells the system to treat one field differently.

The fix isn't "be more careful with logging." It's giving secrets their own lane from the start.

Keeping secrets out of the trail

A webhook call can separate regular inputs from secret ones using a dedicated field, something like _secretStatePut, alongside the normal payload:

curl -X POST "https://your-instance/webhook/trigger-id" \
  -H "Content-Type: application/json" \
  -d '{
    "key1": "value1",
    "_secretStatePut": {
      "apiToken": "sk-live-xxxxxxxxxxxx"
    }
  }'

Anything inside that object gets handled differently from the rest of the payload:

• It doesn't show up in logs or process summaries, unless a step explicitly outputs it (which is on the workflow author, not the platform).
• It's not echoed back in API responses.
• It's only reachable inside the running workflow's own execution context, not from the outside.

Regular inputs still work exactly like before. The only thing that changes is where the sensitive values go.

Where this actually matters

Anywhere a workflow needs to reach something it shouldn't have to show its work on. Triggering a deployment pipeline with environment-specific credentials. Kicking off a data ingestion job that needs to hit a protected API. Any event-driven automation where "what credential did this run use" is a question that should have an answer, just not one sitting in a log file for whoever happens to be grepping through it.

The real value isn't that secrets are hidden. It's that they stop being an afterthought, something a developer has to remember to scrub out of logs after the fact, and become something the platform just handles correctly by default.

If a credential has ever ended up somewhere it shouldn't in your workflow logs, Unmeshed's secret input handling is built to make that the thing that doesn't happen in the first place.