Frequently asked questions

What should a brand-new customer read first?

Start with /getting-started, then /guides/policy-ingestion-and-rag, then the SDK guide for your language.

Do I need to understand Ledgix internals to integrate it?

No. You need to know how to create API keys, upload policy content, send request-clearance calls, handle review states, and optionally verify tokens or proof bundles later.

What happens if a request is pending_review?

Your application should pause the action and let a human reviewer decide later. That is an expected workflow state, not a transport outage.

Should my first integration use the API directly or an SDK?

Most customers should start with the SDK for their language. Use the raw API if you need full control over transport, retries, or automation.

Do I need proof verification on day one?

No. Proof bundles and checkpoint verification are advanced capabilities. Start with a working request-clearance flow and add verification later if your audit process needs it.

What should I upload as policy content first?

Upload the source that genuinely governs the first tool you want to protect. A narrow refund or payment policy is better than a broad handbook that reviewers cannot map to one action.

Can I manage review thresholds and notifications from code?

Yes. Use /review-settings and /notification-settings, or manage the same settings in the customer dashboard.

How do I know which request a reviewer is looking at?

Use the request_id returned by Ledgix. It is the shared identifier across request handling, review decisions, and advanced proof lookups.

When should I add a gateway in front of the protected tool?

Add one when multiple services can trigger the same action or when you want the protected service to require a Ledgix approval token centrally.

What is the most common integration mistake?

Guarding a planner or orchestration step instead of the actual tool call that performs the sensitive side effect.