Get Started with Aeion Legal

legal_settings is a singleton — one row per tenant — that drives default rates, jurisdictions, holiday set, trust protections, and e-signature provider. Create or update it through auto-CRUD:

```bash POST /api/v1/legal_settings { "firmName": "Sterling Law Group", "jurisdictions": ["CA", "NY", "TX"], "defaultHourlyRate": 350, "billingIncrement": 6, "matterNumberFormat": "YYYY-####", "clientNumberFormat": "CLT-#####",

"trustAccountEnabled": true, "trustOverdraftProtection": true, "replenishmentAlertThreshold": 500,

"defaultHolidaySet": "federal", "deadlineWarningDays": 90, "courtDayCalculation": true, "autoCreateDockets": true,

"eSignatureProvider": "native" } ```

> The settings collection is enforced as a singleton — subsequent POSTs return the existing row rather than creating duplicates. Use PATCH /api/v1/legal_settings/<id> to update.

Matters are the core entity. Before creating one, sweep the conflict database for parties already on file.

Record a conflict candidate:

bash POST /api/v1/legal_conflicts { "name": "Johnson & Johnson", "type": "company", "matter": "<existingMatterId>", "side": "opposing" }

Each conflict row stores the normalized name (lowercased, punctuation-stripped, alphabetically sorted words) so fuzzy lookups stay deterministic. To screen a new matter, filter the collection with a string contains operator against your normalized prospect name:

bash GET /api/v1/legal_conflicts?where[name][contains]=johnson

Decide based on the result count (any exact-name hit blocks; partial hits require attorney sign-off). For a programmatic check, query the legal_conflicts endpoint directly from your own integration.

Open the matter:

bash POST /api/v1/legal_matters { "title": "Doe v. Acme Corp", "matterNumber": "2026-0001", "practiceArea": "litigation", "clientContact": "<contactId>", "clientCompany": "<companyId>", "status": "open", "openedAt": "2026-05-20" }

Add opposing parties in legal_matter_parties:

bash POST /api/v1/legal_matter_parties { "matter": "<matterId>", "name": "Acme Corp", "type": "company", "side": "opposing", "role": "defendant" }

Log time against the matter (rate resolved from Step 2's hierarchy):

bash POST /api/v1/legal_time_entries { "matter": "<matterId>", "attorney": "<attorneyId>", "date": "2026-05-20", "hours": 2.5, "description": "Draft motion to compel discovery response", "activityCode": "drafting", "billable": true }

Aeion stores jurisdiction-specific deadline rules in legal_court_rules and statutes of limitation in legal_sol_rules. Both ship with seed data for federal courts plus CA / NY / TX / FL. Dockets — the actionable deadline records — live in legal_dockets.

Inspect available court rules:

bash GET /api/v1/legal_court_rules?where[jurisdiction][equals]=CA

Look up a statute of limitations:

bash GET /api/v1/legal_sol_rules?where[jurisdiction][equals]=CA&where[claimType][equals]=personal_injury

Each rule includes the citation, the limitation period, and the discovery-rule applicability so you can show the source in the UI.

Create a deadline docket:

bash POST /api/v1/legal_dockets { "matter": "<matterId>", "title": "Motion to Compel Discovery Response", "deadlineDate": "2026-06-18", "calculationType": "court_day", "basisDays": 30, "basisDate": "2026-05-15", "warningDays": 7, "jurisdiction": "CA", "assignedTo": "<attorneyId>", "priority": "high" }

Query upcoming deadlines for a matter (next 30 days):

bash GET /api/v1/legal_dockets?where[matter][equals]=<matterId>&where[deadlineDate][before]=2026-06-19&sort=deadlineDate

The dashboard widget pulls the same query and groups by status (upcoming / due / overdue).

IOLTA trust ledger. Every deposit and withdrawal is a row in legal_trust_ledger linked to a matter. Balances are computed from the ledger — no separate stored balance to drift.

```bash # Initial retainer deposit POST /api/v1/legal_trust_ledger { "matter": "<matterId>", "transactionType": "deposit", "amount": 5000, "description": "Advanced retainer deposit", "referenceNumber": "CHK-12345", "authorizedBy": "<attorneyId>", "transactionDate": "2026-05-20" }

# Withdrawal to pay an invoice POST /api/v1/legal_trust_ledger { "matter": "<matterId>", "transactionType": "withdrawal", "amount": 1000, "description": "Invoice #123 paid from trust", "authorizedBy": "<attorneyId>" } ```

Withdrawals are guarded automatically: requesting more than the matter's current balance is rejected with an error that includes the available balance and the requested amount, so your UI (or your own integration) can show exactly why it was blocked. Corrections (transactionType: "correction") require an authorizing user and bypass the guard for legitimate ledger fixes.

Compute matter balance by aggregating the ledger:

bash GET /api/v1/legal_trust_ledger?where[matter][equals]=<matterId>&sort=-transactionDate

Sum deposits minus withdrawals client-side, or pull the same computed balance through the trust ledger endpoint for your own reporting.

Contract Lifecycle Management. Beyond auto-CRUD on legal_contracts, contract_versions, contract_obligations, and contract_compliance_tags, Aeion ships a dedicated CLM router at /api/legal/clm/* for obligation tracking, renewal scheduling, version control, and portfolio analytics:

```bash # Auto-extract obligations from a signed contract POST /api/legal/clm/obligations/<contractId>/extract

# Mark an obligation complete PATCH /api/legal/clm/obligations/<obligationId>/complete

# Mark an obligation in breach PATCH /api/legal/clm/obligations/<obligationId>/breach

# Upcoming renewals (next 90 days) GET /api/legal/clm/renewals/upcoming

# Save a new version with diff capture POST /api/legal/clm/versions/<contractId>

# Compare two versions side-by-side POST /api/legal/clm/versions/compare { "fromVersionId": "...", "toVersionId": "..." }

# Portfolio-wide analytics GET /api/legal/clm/analytics/portfolio GET /api/legal/clm/analytics/obligations GET /api/legal/clm/analytics/vendors GET /api/legal/clm/analytics/compliance GET /api/legal/clm/analytics/timeline/<contractId> ```

A daily check at 08:00 sweeps contracts at risk of lapsing and sends reminders — or auto-renews them — based on each contract's configured renewal policy.