Native REST API for Password Secure instead of mandatory SDK integration

Password Secure Password Secure Ideas
, ,
1

Summary of the Proposal

We want an officially supported, fully documented, and versioned REST API that allows Password Secure to be integrated directly via HTTPS and JSON—regardless of programming language, runtime, and proprietary client SDKs.

Problem Description and Motivation

We integrate Password Secure into various applications and automations, including C# services and PowerShell scripts. The central use case is the controlled retrieval of credentials at runtime.

According to the current SDK/API documentation, API access is provided through the C# and JavaScript SDKs. As a result, integrations must account not only for the interface communication itself, but also for SDK versions, transitive dependencies, and runtime requirements.

This coupling creates additional development and operational effort:

  • SDK dependencies must be compatible with the libraries already used by an application.
  • Server updates may require updates to the embedded SDKs and redeployments of the consuming applications.
  • Dependency conflicts can affect integrations even though their functional use case has not changed.
  • Other programming languages and platforms require additional wrappers or their own integration solutions.

A specific incident after an SDK update caused us assembly loading conflicts involving MessagePack, System.Collections.Immutable, and System.Text.Json. In the affected integration, even the initialization order had to be adjusted compared to another library.

This incident highlights the underlying problem: Access to a centralized password store is tied to the local library and runtime environment of the consuming application.

Desired Solution

We want direct REST access with the following characteristics:

  • Standardized HTTPS/JSON communication, usable for example with HttpClient in C#, Invoke-RestMethod, Python, or curl.
  • A complete OpenAPI specification with documented endpoints, data models, authentication flows, and examples.
  • Appropriate authentication for applications and unattended automations, with limited permissions and revocable access.
  • Targeted secret retrieval by stable IDs, search and metadata capabilities, as well as documented administrative operations.
  • A stable, versioned interface contract with clear compatibility commitments, announced breaking changes, and transition periods.
  • Traceable error handling via HTTP status codes and structured error messages.

The existing authorization, auditing, and encryption approach should be retained. Any required authentication or cryptographic steps should be fully documented and implementable without proprietary client libraries.