How Ledgix fits into your stack

Ledgix sits between your application and the sensitive tools or services you want to protect. The customer-facing picture is simpler than the internal runtime: your app asks for clearance, Ledgix returns a decision, and your team uses the dashboard to manage policies and reviews.

The customer-visible pieces

Field	Type	Required	Description
Your application	App or worker	Yes	The service or agent that wants to run a sensitive action such as a payment or refund.
Ledgix SDK or API call	Integration point	Yes	The request your code makes before it performs the protected action.
Customer dashboard	Web app	Yes	Where your team creates API keys, uploads policy content, manages reviews, and configures notifications.
Optional gateway	Protected service edge	No	A layer in front of your tool or service that accepts only approved Ledgix tokens.
Verification APIs	Advanced audit surface	No	Ledger, checkpoint, and proof endpoints for teams that need independent verification.

The flow most customers implement

High-level flow

Step 01

Your app asks Ledgix for clearance

The SDK or direct API request includes the tool name, the exact tool arguments, and identifiers such as agent_id and session_id.

Step 02

Ledgix returns a decision

The response is approved, denied, pending_review, or processing. Approved responses include a token for the specific request.

Step 03

Your team operates the result

Your app executes only approved actions, reviewers handle pending items, and advanced teams can later verify the resulting evidence with proof APIs.

Where the dashboard fits

The customer dashboard is part of the normal operating path, not an afterthought. Most teams use it to:

create and rotate tenant API keys
upload or import policy sources
tune the minimum confidence threshold
configure Slack or email notifications
approve or deny requests in the review queue

Where the SDK fits

The SDK belongs at the exact tool boundary you want to protect. Good examples:

issuing a refund
creating a payment
writing to a CRM
executing an admin action

Poor examples:

wrapping a generic planner step
approving a broad natural-language intent without the final tool arguments
guarding a helper function that never performs the real side effect

When to add the optional gateway

Use a gateway when you want the downstream tool or service to require a Ledgix token before it accepts the action. That pattern is useful when:

multiple services can trigger the same protected action
you want the protected service to reject unapproved calls centrally
you need a clean authorization boundary in front of an internal tool

If your first integration is simple, you can start with direct SDK calls and add a gateway later.

What this page intentionally leaves out

You do not need internal hosting, storage, or model pipeline details to complete a customer integration. Those details are not part of the public onboarding path.