The Esqase API
Esqase has a public REST API that lets your own systems read and write the data in your firm. If your firm already keeps client records, cases, or prospects in another tool (an old practice-management system, a spreadsheet pipeline, a custom intake script), you can use the API to push that data into Esqase automatically instead of re-typing it by hand.
This page explains what the API is for, who can use it, and how the pieces fit together. The pages that follow walk through creating a key, authenticating your requests, and working with each kind of record.
What the API is for
The API is built around one job: syncing structured records between your existing systems and Esqase. With it you can:
- Create and update contacts (the people and companies your firm works with).
- Create and update matters (your cases and engagements).
- Create and update leads (prospective clients in your intake pipeline).
- Create and update practice areas and matter types (the areas of law your matters are organized under).
- Read any of the above back out, one record at a time or in pages.
Anything the API creates or changes behaves exactly like a record made by hand inside Esqase. It shows up everywhere in the app, it is written to your firm's audit log, and contacts and matters become searchable the moment they are created. There is nothing "second-class" about an API record.
Note: The API is for moving structured records (contacts, matters, leads) in and out of Esqase. It is not a way to drive the whole app from the outside. Billing, documents, e-signature, scheduling, and the rest of Esqase stay in the dashboard.
Who can use it
Working with the API takes two things:
- An API key. A key is a long secret string that stands in for a person at your firm. Anyone building the integration needs a key, and only firm owners and administrators can create one. See Managing API keys.
- Someone who can write a little code (or a tool that can). The API speaks HTTP and JSON, the common language of web integrations. If you have a developer, an IT person, or an automation tool (such as a no-code platform that can call a REST API), they have everything they need.
If your firm does not have anyone who works with APIs, you do not need this section at all. Everything the API does can also be done by hand in the dashboard.
How it is organized
The API lives at its own address, separate from the app you log in to:
- The app you and your team use is the dashboard.
- The API is a separate service for machines, reached at
https://api.esqase.com.
You do not visit the API address in a browser to get work done. Instead, your integration sends requests to it in the background, and Esqase sends data back.
Every request you send needs to prove who it is (with an API key) and is allowed to touch only the kinds of data you granted that key. The rest of this section breaks that down:
- Managing API keys: create a key in the dashboard, choose what it can do, copy it safely, and revoke it when you are done.
- Authentication and scopes: how a request proves who it is, how "scopes" limit each key to the data it needs, and where to find the machine-readable OpenAPI spec.
- API resources and endpoints: the contacts, matters, leads, practice areas, and matter types endpoints, their fields, paging, and errors.
Looking for runnable examples? Authentication and scopes has a copy-paste quickstart (curl, JavaScript, Python, and Postman) for making your first authenticated request, and API resources and endpoints has request and response examples for each endpoint.
A note on safety
The API was built to be careful with your firm's data. In plain terms:
- A key is shown to you once and then stored only in a scrambled form, so even Esqase cannot read it back.
- A key is scoped to the least it needs. A key meant only to read contacts cannot create matters or touch leads.
- A key can never do more than the person who created it can do. If the member who made the key only has view access to matters, the key cannot create matters either.
- A key can optionally be restricted to specific browser domains (an allowlist you set when you create the key, or edit later). If a key is used from a web page whose domain is not on the list, that browser request is rejected. Server-to-server calls (curl, Postman, backend SDKs) send no browser origin, so they are never blocked by this setting. See Authentication and scopes for how allowed domains work.
- Every change made through the API is written to your audit log, noting which key did it.
- There is a rate limit so a runaway script cannot overwhelm your firm's data.
The full breakdown of each of these is in Authentication and scopes.