
Proof CLI (unofficial)
io.github.tsarleweyv0.3.1更新于 Sep 30, 2026
Notarize, e-sign, and verify identity with the Proof API. Unofficial; not affiliated with Proof.
安装
在 SourceWeft 中
- 打开 控制台中的 Proof CLI (unofficial),将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
Proof CLI
An unofficial command-line interface for interacting with the Proof API. The Proof CLI provides access to Business, Real Estate, and SCIM APIs through a unified interface.
This is an alpha product and should be treated as such. It is not an official product from Proof.
Installation
Prebuilt binary
Windows zips and checksums are on the Releases page.
Install via Go
From Source
Use with AI agents
Claude Code plugin (bundles a usage skill and the MCP server; needs proof on your PATH):
MCP server for any MCP client. proof mcp exposes every API command as a tool over stdio, annotated read-only or destructive:
For other clients, run the command proof mcp. It reads credentials the same way as the CLI (PROOF_API_KEY or proof config).
Docker, with nothing installed locally. The image runs proof mcp and is listed in the MCP Registry as io.github.tsarlewey/proof-cli:
Arguments after the image name go to proof mcp, e.g. --read-only. PROOF_API_ENDPOINT overrides the configured endpoint in any mode; leave it unset for production.
Agents using the shell can follow skills/proof/SKILL.md. Output is JSON (--pretty=false for compact), and API errors exit 1 with the response body on stderr. Point at the sandbox while testing: proof config set-endpoint https://api.fairfax.proof.com.
Getting Started
1. Configuration
Before using the CLI, you need to configure your API key:
In order to get an API Key, you'll need an account with API Usage. You can get that here - https://www.proof.com/pricing#business
After your account is created and upgrade use https://dev.proof.com/docs/api-keys to setup your key.
OAuth 2.0 Authentication
The CLI supports OAuth 2.0 client credentials flow for secure API authentication:
OAuth tokens are automatically refreshed before expiration (5-minute buffer).
2. Basic Usage
The CLI is organized into three main API groups:
business- Business API operations (transactions, documents, webhooks, notaries, etc.)real-estate- Real Estate/Mortgage API operationsscim- SCIM API operations for user management
API Reference
Business API
The Business API provides comprehensive transaction and document management capabilities.
Transactions
Documents
Webhooks
Notaries
Templates
Referrals
Integrations
Real Estate API
The Real Estate API specializes in mortgage and real estate transaction management.
Transactions
Templates
Documents
Webhooks
Address Verification
SCIM API
The SCIM API provides standardized user management capabilities.
Users
Schemas
Security Events API
Read the organization's OCSF-formatted security event log.
Certificates API
Issue, use, and revoke organization certificates.
Verifiable Credentials API
Requests a Verifiable Credential presentation from an End-User. This endpoint is a browser redirect, not a server-to-server call — the CLI prints the URL for you to send the End-User to, and does not follow it.
--redirect-uri is required in fragment mode and rejected in direct_post
mode; --response-uri is the reverse. Both URIs must be registered on your
OAuth Application.
Examples
The CLI includes example commands that demonstrate common workflows:
Configuration
The CLI stores configuration in ~/.proof-cli/:
config.json- Main configuration fileapi_key- API key (permissions 0600)
Configuration options:
endpoint- API endpoint URLtimeout- Request timeout in seconds
Global Flags
All commands support these global flags:
--pretty- Pretty print JSON output (default: true)--verbose- Show additional debug output--help- Show help information
Environment Variables
PROOF_API_KEY- API key for authenticationPROOF_ENDPOINT- Override default API endpointPROOF_TIMEOUT- Request timeout in seconds
Error Handling
The CLI provides detailed error messages and uses standard exit codes:
0- Success1- General error (API error, invalid arguments, etc.)
Development
Building from Source
Makefile Targets
The project provides a Makefile for common development tasks:
SDK Source
The generated Go SDK clients now live in their own repo: github.com/tsarlewey/proof-sdk-go. This CLI imports them as a regular Go module dependency. If you need to regenerate the clients after an upstream OpenAPI spec change, work inside the SDK repo — the generation toolchain (OpenAPI specs, oapi-codegen configs, preprocessing scripts, make regenerate) moved there.
To pick up a new SDK release in this CLI:
Adding or Updating Commands
CLI commands live in cmd/ (one file per API surface) and are built with Cobra. Each command's Run closure calls a method on the generated SDK client via the factory helpers in cmd/root.go (getBusinessClient, getRealEstateClient, getSCIMClient). The factories wrap the SDK client with common.AuthenticatedDoer (from the SDK repo), which injects OAuth bearer tokens or the API key on every request.
Shared helpers in cmd/root.go:
initializeForAPICall— lazy client setup, used asPreRunon every API-calling command.PrintResponse/PrintVerbose— response output with optional pretty-printing and colorization.parseDateFlag— parses optional date-flag values, exits with a clear message on parse failure.isSuccess— 2xx status-code check.checkAPIStatus— after every SDK call, exits 1 with the body on stderr if the API returned a non-2xx response.
Errors from SDK calls are funneled through utils.HandleError(err, "action phrase") for transport errors and checkAPIStatus(resp.StatusCode(), resp.Body, "action phrase") for application-level HTTP errors. Both exit 1.
Support
For issues and feature requests, please visit the GitHub repository.
License
来源:README.md,提交 c7aa383
工具
0版本历史
1- v0.3.1最新Sep 30, 2026


