Blawby

Last verified

Blawby Developer Reference

This page is the honest map of what's available to developers integrating with Blawby today, and what's on the roadmap.

About this page — Blawby's product is a hosted application for law firms. The integration surfaces below are what's stable enough to build against right now. The full public REST API is still being designed; sign up for early access at the bottom of this page if you need it.

What's available today

1. Embeddable chat widget

The chat widget is the primary integration surface. Drop a script tag on your law firm's website and the widget renders the live intake experience: AI-guided conversation, file uploads, optional consultation fee collection, and submission into your firm's queue.

See Install the Chat Widget for setup.

What the widget supports:

  • AI-guided intake in 18 languages with full RTL for Arabic.
  • File attachments up to 25 MB per file (images, video, audio, PDF, Word docs).
  • Optional consultation fee collection via Stripe before submission.
  • Conditional intake fields (the AI only asks follow-up questions when a parent answer matches).
  • Cross-origin cookie handling — the widget is designed to work when embedded on your firm's domain, not Blawby's.

Generate a payment link in the dashboard, then customize the amount per request via a URL parameter. This works in email, SMS, intake email replies — anywhere a link works.

https://blawby.com/your-firm-slug?amount=12500

The amount parameter is in cents. 12500 = $125.00. See Accepting Payments for the full link reference.

3. Notification channels

When something happens in your firm (intake submitted, invoice paid, engagement signed, matter status changed) Blawby fans out notifications across:

  • In-app — bell icon in the dashboard.
  • Email — transactional, branded with your firm.
  • Push — via OneSignal SDK on the web client.

You don't subscribe to these as a developer today; they're delivered to your team's accounts. Server-to-server webhook delivery is on the roadmap (see below).

4. Paralegal document analysis (in-product)

When clients upload documents into chat, an AI paralegal streams analysis status messages and surfaces extracted facts, deadlines, and risks. This is currently surfaced inside the Blawby app — the underlying analysis WebSocket is not yet a public integration point.

What's on the roadmap

These are the integration capabilities being designed but not yet released for public use:

  • Public REST API — programmatic CRUD for matters, invoices, contacts, intakes, and time entries.
  • Webhooks — subscribe to events like intake.submitted, intake.accepted, engagement.signed, invoice.paid, payout.created. HMAC-signed, with idempotency keys.
  • OAuth 2.0 for third-party apps — let other tools connect to a Blawby practice on behalf of a user.
  • SDK packages — @blawby/sdk for JS/TS and a Python equivalent. None are published today.
  • Granular role-based API tokens — scoped tokens (e.g., intake.read, invoices.write) for service integrations.

Authentication today

End-user authentication is handled by Blawby's hosted Better Auth deployment. Sessions are issued as cookies and validated server-side; there is no public API key issuance yet.

If you need session-aware behavior in your own service while we work toward an API:

  • Mount the chat widget on a page your authenticated user is already on.
  • Pass a stable practice slug or organization identifier in the embed snippet so the widget routes to the right firm.
  • Treat any data the widget posts back to your domain (e.g., a thank-you page) as untrusted user input — Blawby is the source of truth.

Security expectations for the future API

When the public API ships, integrations should plan for these baseline behaviors. Building against these expectations now will save migration work later:

  • HTTPS only. No plaintext.
  • Webhook verification with HMAC-SHA256 over the raw request body. Compare with crypto.timingSafeEqual (Node) or constant-time equivalents.
  • Idempotency keys on any state-changing call so retries don't duplicate writes.
  • Exponential backoff with jitter on rate-limit responses.
  • Never embed credentials in client-side code. Calls must originate from a server you control.

A representative HMAC verification — pattern only, the real signing scheme will be published with the API:

import crypto from "node:crypto";

function verifyWebhookSignature(rawBody, signature, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody, "utf8")
    .digest("hex");
  return crypto.timingSafeEqual(
    Buffer.from(expected, "hex"),
    Buffer.from(signature, "hex"),
  );
}

Get early access

If your team needs the public API or webhooks now, contact developer support. Priority is given to firms with a concrete integration use case (CRM sync, accounting, document management).