Understanding APIs

How software systems talk to each other. Why an API is often described as the waiter of the web — you do not go into the kitchen, you place an order and something comes back — and where those connections already sit inside legal work you do every day.

The request and response activity

The video asks you to read this object aloud and say what each line is telling you.

{
  "student_id": "sls_2026",
  "name": "Jane Doe",
  "courses": ["Law & Tech", "Prototyping 101"],
  "active": true
}

Building on module one, this goes a layer down into the plumbing: how a service knows it is you, what a key is and how badly it matters, and how to read an error rather than guess at it.

Lab snippets

The two halves of the authentication segment: what you send, and what comes back when it is wrong.

Authorization: Bearer sk_live_51M7…

{
  "error": {
    "code": "unauthorized",
    "message": "Invalid API Key provided."
  }
}

One API is rarely the whole story. This module puts a single connection back into the system around it — several services, each with a job, each depending on others — which is the shape most legal technology actually arrives in.

The microservices exercise

Read this the way the video does: two services, one of which cannot start until the other is up. The indentation is the whole meaning, which is why a stray space breaks a file like this.

services:
  - name: "case-management"
    port: 8080
    dependencies: ["auth-service", "database"]
  - name: "client-portal"
    port: 3000
    dependencies: ["case-management"]

The hands-on module. You script a small legal automation end to end: connect, ask for a document, have something judge it, and return an answer a person can act on. The recording calls this the “Vibe Protocol”; the pattern underneath it is the same one every integration follows.

Setting up the environment

Connections carry settings, and two of them are worth arguing about before you write anything else: where the data is allowed to sit, and which rules apply to it.

// Open the connection with its constraints declared up front.
client.connect({
  mode: "secure",
  region: "us-west-1",
  compliance: ["GDPR", "CCPA"]
});

One step of the workflow

Fetch, assess, decide. Note that the decision is a threshold you chose, not something the model handed you — and that a flag routes the document to a person rather than closing the matter.

// Define one action in a review workflow.
async function reviewContract(docId) {
  const doc = await client.docs.get(docId);
  const risk = await client.ai.analyzeRisk(doc);
  return risk.score > 80 ? "FLAGGED" : "APPROVED";
}

What changes when the thing calling the API decides for itself which call to make next. How agents are given an objective, a boundary, and a budget — and why the boundary is the part you should spend your time on.

Configuring an agent

Everything in this file is a limit. permissions says what it may touch; max_steps says when it must stop even if it has not finished.

{
  "agent_name": "legal_research_assistant_v1",
  "permissions": ["read_case_files", "web_access"],
  "model": "<your model here>",
  "max_steps": 10
}

Giving it a task

A usable objective is narrow, and the constraint is doing as much work as the objective. Compare what this asks for against “research IP theft cases”.

const task = await agent.createTask({
  objective: "Summarize recent precedents for IP theft in virtual worlds.",
  constraints: "Focus on Ninth Circuit decisions after 2024.",
  output_format: "memo"
});

await agent.execute(task);

Shipping is the start, not the finish. How to write a test for something that answers differently every time, and how to notice a system degrading before the person relying on it does.

A test with a fixed input

The trick with a non-deterministic system is to test a claim rather than a string: this contract is risky, and indemnification is one of the reasons.

describe('Contract review', () => {
  it('should flag high-risk clauses', async () => {
    const doc = await loadFixture('risky_contract.pdf');
    const result = await agent.analyze(doc);
    expect(result.riskScore).toBeGreaterThan(80);
    expect(result.flags).toContain('Indemnification');
  });
});

What to watch once it is running

Two numbers and a place to send them. Alerting nobody reads is not observability.

{
  "alerting": {
    "latency_threshold_ms": 1500,
    "error_rate_threshold": 0.05,
    "channels": ["slack-ops", "email-admin"],
    "log_level": "DEBUG"
  }
}

The last module steps back from the code. What it means to be accountable for something that acts on your behalf, which commitments are worth writing down before you need them, and where to take this after the course ends.

Commitments, written down

A policy in a configuration file is a policy someone can check. These four are a starting point, not a complete list — and each one has to mean something you would actually enforce.

{
  "ethics_policy": {
    "human_in_the_loop": true,
    "transparency": "maximum",
    "bias_mitigation": "active",
    "data_privacy": "strict"
  }
}

The improvement loop

Reflect, adjust, review. The third line is the one that keeps this a tool rather than a process running without you.

// The loop of continuous improvement.
async function improve() {
  const insights = await agent.reflect();
  await agent.optimize(insights);
  await human.review(); // not optional
}