Hey folks, ran into a real head-scratcher this week and wanted to share the solution in case anyone else hits this. We're evaluating Delinea's Secret Server for managing our CI/CD service account SSH keys. The goal was to rotate and check in a new deploy key via the API from a secure runner.
The issue? Our script to add the key to a project would complete with a `200 OK`, but the key was never actually added to the project. No error in the response body, no logs in the UI—just silent failure. Took a solid afternoon to debug! 🔍
Here's the crux: the API call *seemed* simple. We were using the standard `POST` to the `/api/v1/secrets/{id}/check-in` endpoint with a minimal payload. Our initial JSON body looked like this:
```json
{
"autoChangeEnabled": false,
"password": "-----BEGIN OPENSSH PRIVATE KEY-----..."
}
```
Turns out, the **`secret` field name is the culprit**. For SSH Private Key type secrets, you must pass the key material under the field `"password"` in the check-in payload. If you follow the generic documentation and use `"secret"` or `"items"`, it succeeds silently but does nothing.
The corrected payload:
```json
{
"autoChangeEnabled": false,
"password": "actual-ssh-private-key-content-here"
}
```
Lessons learned:
* The Secret Server API uses different field names for different secret types during check-in.
* Always double-check the secret type's specific required field in the payload, don't rely on the generic template.
* A `200` response doesn't guarantee the operation was semantically correct—it just means the request was accepted.
Has anyone else encountered similar field mapping pitfalls with the API? Would love to hear how you've automated secret rotations reliably.
-pipelinepilot
Pipeline Pilot
Oh wow, that's a fantastic and very specific find. Thanks for sharing this - silent failures on API calls are the absolute worst, and the field name mismatch you described is exactly the kind of undocumented quirk that burns hours. It makes you wonder if the endpoint is re-using generic internal logic that expects a 'password' field for any single, primary secret value, even when it's an SSH key.
I've seen similar things in other B2B APIs where the secret type dictates the required JSON schema, but the documentation just shows the generic case. Your post just saved a bunch of people from that same frustrating afternoon. 😅
Did you happen to find if this behavior is consistent across all their 'private key' secret types, or just the SSH variety?
Let's keep it real.
It's not just SSH private keys. We ran into the same silent failure with a generic PEM key. The API was returning a 200, the log said "check-in successful", but the actual file field was empty.
I had to wire up a proxy to see their internal API validation. The "privateKey" field name is indeed the trigger, but the mapping is based on the secret template's "password" field mapping, not the key type. So if your custom template maps the primary secret to a field called "credential", you'd probably need to use that.
Their docs treat this as an implementation detail they shouldn't have to document. Makes integration a guessing game.
-- bb