Customer developer docs

Customer quickstart

Create your API key, add policy content, set review controls, and run your first guarded request.

Customer quickstart

Ledgix is easiest to adopt when you treat it as a customer workflow, not just an API. Start by giving your team access to the dashboard, add policy content, decide how manual review should work, and only then wire the SDK into the tool you want to guard.

Outcome

By the end of this quickstart, you should have one tenant API key, one policy source, one review path, and one guarded request running end to end.

What you need from Ledgix

  1. 01
    Customer dashboard access
    An administrator on your team needs access to the Ledgix customer dashboard so they can create API keys, upload policy content, and manage review settings.
  2. 02
    Your Vault URL
    Every SDK call and direct HTTP request goes to the Vault URL for your environment. Keep separate values for development, staging, and production if you use multiple environments.
  3. 03
    One policy source
    Bring a real policy document, SOP, or rule set that should govern the first sensitive action you want to guard. If the policy is not ready, finish that work before judging the integration.
  4. 04
    One sensitive tool boundary
    Pick the exact action you want Ledgix to protect first. A refund, payment, CRM write, or admin action is a better starting point than a vague 'assistant workflow'.

First-day setup path

  1. 01
    Create a tenant API key
    In the customer dashboard, open Settings and create a named API key for the service that will call Ledgix. Save the raw key immediately because it is shown only once.
  2. 02
    Upload or import policy content
    Use Upload to add a file, paste policy text, or import an optional Confluence page. Keep the policy focused on the exact action you plan to guard first.
  3. 03
    Set review and notification defaults
    Open Reviews to choose a starting minimum confidence score, then use Settings to turn on Slack or email notifications so pending reviews do not sit unnoticed.
  4. 04
    Integrate one SDK path
    Use the TypeScript or Python SDK to wrap one real tool. Your first goal is to handle approved, denied, and pending-review outcomes cleanly, not to wire every action at once.

Suggested environment variables

TypeScript
// ledgix.json
// {
//   "enforce": [
//     { "tool": "createStripe*", "policyId": "stripe-agent-prod" }
//   ]
// }

import * as rawTools from "./tools.js";
import { configure, autoInstrument } from "ledgix-ts";

// Configure once at startup
configure({ agentId: "payments-agent" });

// Instrument any matching exported tools — no signature changes
const tools = autoInstrument(rawTools);
First customer workflow
Step 01
Set up the tenant
Create an API key, add a policy document, and configure the first reviewer notification path before you send live traffic.
Step 02
Guard one action
Wrap one payment or refund tool with Ledgix so the exact request arguments are evaluated before the side effect happens.
Step 03
Exercise all outcomes
Run test requests that produce approved, denied, and pending-review responses. The integration is not finished until your team can handle all three.

What success looks like

  • Your application can call request-clearance through the SDK or API.
  • Your team knows who reviews pending_review requests and where the notifications go.
  • Your first guarded tool behaves differently on approved, denied, and pending_review.
  • You know where to inspect the result afterward in the dashboard or proof APIs.

Where to go next

Common first-day mistakes

  • Testing against an API key you created for the wrong environment.
  • Uploading broad policy text that does not clearly govern the tool you are actually protecting.
  • Ignoring the pending_review path and treating it like a failure instead of an intentional pause for human approval.
  • Wrapping a high-level planner step instead of the real tool call that performs the sensitive action.