Retrieve a configuration proposal
Authentication
A secret key (rl_sk_test_..., rl_sk_live_...) or a restricted key with limited scopes (rl_rk_test_..., rl_rk_live_...). A restricted key can carry agent: true and an expires_at, and is what a coding agent should hold. Keys end in a checksum so secret scanners can recognize them. People create, roll and revoke keys in the dashboard; GET /v1/api_keys lists them, masked.
Path parameters
The config proposal ID (cprop_...).
Response
pending until a person decides or 7 days pass, then approved, rejected or expired.
Everything an agent or person configures, in the shape the create requests take. Leave a section out to leave it alone. Objects with a key are matched by key, webhook endpoints by url. Routing rules and notification rules are ordered lists that replace the current ones. Payment providers are connected with POST /v1/payment_providers, because a person completes that step.
Who made a change. Runledger fills it in from the credential, so a client can’t claim to be someone else: an API key always acts as itself, the dashboard calls the API as the signed-in person, and the MCP server passes the client’s name and the person it acts for. A request that sends a Runledger-Actor header is refused with 400 parameter_unknown.
The configuration hash the proposal was made against. Approving after the configuration has changed returns 409 with invalid_state.
Who made a change. Runledger fills it in from the credential, so a client can’t claim to be someone else: an API key always acts as itself, the dashboard calls the API as the signed-in person, and the MCP server passes the client’s name and the person it acts for. A request that sends a Runledger-Actor header is refused with 400 parameter_unknown.