The REST API
Most of what you do in the dashboard, you can do programmatically. The Dregs REST API covers identities, events, scores, escalations, and configuration, while team members, credentials, and billing stay in the dashboard. Build custom integrations, automate workflows, and embed fraud intelligence directly into your application.
Before writing against the REST API directly, check whether an official server SDK covers what you need. There is one for Python, Node, Java, Ruby, and PHP, and they wrap event tracking, identity and score reads, and webhook verification with retries and typed errors. The API below is what they call, and remains the right answer for anything outside that surface.
Authentication
The public API authenticates with one of your API credential's keys in the
Authorization header. Your server-side calls use the secret key; the tracking
script uses the public key, and only on the two routes that accept it.
Customer Secret Keys
A credential's secret key starts with sk_. Create one
under Settings → Credentials and keep it on your
server, because it acts as an admin of that credential's team. Send it on each request:
Authorization: Bearer sk_your_secret_key_here
The operations you can call this way are listed in the public OpenAPI document.
Don't confuse the secret key with a webhook signing secret. Your API credential's secret key authenticates your requests to the Dregs API, while a webhook channel's signing secret lets you verify that incoming webhook payloads came from Dregs. See Webhooks for details on signature verification.
Customer Public Keys
A credential's public key starts with pk_. It's the
key you embed in the tracking script. Send it the same way:
Authorization: Bearer pk_your_public_key_here
A public key is accepted on POST /api/events and on
GET /api/devices/{fingerprint}. Every other route in the public
document expects the secret key.
MCP Tokens
MCP tokens (they start with dmcp_) authenticate AI agents at the
Dregs MCP server only. You create them under
Settings → AI Agents. They act as the user who created them within that team,
and are refused by every REST endpoint, so a token issued to an agent cannot be turned into API
access. Agents that support OAuth do not need one.
Key Endpoint Groups
The API is organized around the core entities in Dregs. Here is an overview.
Events
The tracking script sends events via POST /api/events, authenticated
with the public key. Your backend can send the same request with the secret key.
Reading events via GET /api/events requires the secret key and returns
a paginated, filterable list of tracked events for your account.
Ingestion reports its outcome with the HTTP status code: 200 when the
event is accepted, 400 for a malformed body or an event carrying neither
an identity nor a device, 401 for an unrecognized key, 402
when the account is over its monthly event limit, and 429 when the
credential exceeds its ingestion rate limit. A few rejections are deliberately quiet:
an event from an origin the public key does not allow, one carrying a malformed
device signature, or one whose client-supplied id fails validation
(longer than 64 characters, or starting with dregs-), returns
200 with a null id rather than
telling the caller which check it failed.
Include an id in the body to make ingestion idempotent. Reposting the same
id returns the original event instead of recording a second one, which
makes a retry after a timeout safe. The value must be at most 64 characters and must not
start with dregs-, which is reserved for identifiers Dregs generates.
Identities
List all identities, get detail for a specific identity, retrieve scores and analysis results, and trigger a re-analysis. The identity endpoints are the core of the API: they expose the scores and observations that drive your fraud decisions.
GET /api/identities: paginated list with search and filteringGET /api/identities/{id}: full identity detailGET /api/identities/{id}/scores: the four current category scoresGET /api/identities/{id}/analysis: the most recent analysis cycle, with the observations behind each scorePOST /api/identities/{id}/actions/analyze: trigger re-scoring
The {id} in identity endpoints is the same identifier you pass
to dregs.identify(): your external user ID, not an internal
database ID. If you identify users with dregs.identify('user_12345'),
you retrieve their scores with GET /api/identities/user_12345/scores.
Groups
Groups are the organizations, companies, teams, workspaces, and other collectives your
users belong to. They are created by events that carry groups; see
Groups for the event format. A group is addressed
by its type and ID.
GET /api/groups: paginated list with member counts; filter bytype, or byidentityto list the groups one identity belongs toGET /api/groups/{type}/{id}: full group detail, including its dataPATCH /api/groups/{type}/{id}: merge newattributesinto a groupPUT /api/groups/{type}/{id}/identities/{identityId}: add an identity to a groupDELETE /api/groups/{type}/{id}/identities/{identityId}: remove an identity from a group
To list the members of a group, filter identities by it:
GET /api/identities?group=team_42&groupType=team. Events take the same
filter. When groupType is omitted it is organization.
Devices
List fingerprinted devices with the secret key, or fetch one device by fingerprint.
GET /api/devices/{fingerprint} also accepts the public key, which is
how the tracking script reads device info. Updating a device requires the secret key.
Escalations
List escalations with filtering by status, severity, and identity via
GET /api/escalations. Get one escalation with
GET /api/escalations/{id}, update its status (acknowledge or close)
with PATCH /api/escalations/{id}, and retrieve summary counts with
GET /api/escalations/summary. These endpoints let you build triage
workflows outside the dashboard.
Escalation Rules and Badge Rules
The API offers full CRUD for escalation rules at /api/escalation-rules and
for badge rules at /api/badge-rules. Escalation rules open escalations when scores or badges match conditions
you define, and badge rules label identities automatically. Creating, updating, and
deleting rules requires the Admin role.
Channels
Create and manage notification channels (email, Slack, webhook), send test deliveries to verify an integration, and view delivery history for any channel. See Channels and Webhooks for details on channel types and webhook configuration.
Dashboard
Programmatic access to the same data the home page displays: aggregate stats, score distributions, and recently active identities. Use it to build custom dashboards or to feed Dregs data into your other monitoring tools.
Datasets
Create and manage datasets and their entries. The API supports bulk operations (replace all entries in a dataset or append new ones), making it the right tool for importing datasets from external sources.
Team
Team membership, invitations, and API credentials are managed in the dashboard, under Settings → Team and Settings → Credentials. Those routes are tied to a signed-in dashboard session and are not part of the published OpenAPI. Create a secret key there, then call the API with it.
Pagination
All list endpoints return paginated results. Control pagination with these query parameters:
pageNumber: the page to retrieve (zero-indexed)pageSize: number of items per pagesort: the field to sort by (varies by endpoint)
Responses include the items for the current page plus metadata: total items, total pages, current page number, and page size. This gives you everything you need to build pagination controls in your own UI.
Filtering
Most list endpoints support filtering parameters specific to the entity type. The
term parameter provides free-text search across relevant fields. For
identities, it searches identifier, display name, email, and username. For
events, it searches event name, IP address, and identity. For devices, it searches
fingerprint, IP, city, country, and user agent. For groups, it searches identifier
and name.
Structured filters are also available. Identity endpoints accept score range parameters and a group filter. Event endpoints accept identity, group, and fingerprint filters. Escalation endpoints accept status and severity filters. Filters combine freely, so you can use several in a single request to narrow results precisely.
API Design Conventions
The API follows RESTful conventions throughout. Standard CRUD operations use the
expected HTTP methods: GET for reads, POST for creates,
PATCH for updates, DELETE for deletes.
Non-CRUD operations (actions that trigger side effects or state changes rather than
modify a resource) use POST to /actions/
sub-paths. Triggering a re-analysis is
POST /api/identities/{id}/actions/analyze. This convention distinguishes
a plain data operation from a more significant action.
Responses use versioned V1 types rather than Dregs's internal data models, so the contract you code against stays stable and includes only the data you need, with no sensitive internal fields.
Response Examples
The following examples show the JSON response structure for common endpoints.
Authenticated requests send Authorization: Bearer followed by the
secret key. The two routes that also accept a public key are called out above.
Identity Detail
GET /api/identities/{id} returns the identity's profile, current scores,
badges, and timestamps. Scores are integers from 0 to 100, or
null if the identity hasn't been scored yet.
{
"id": "user_12345",
"displayName": "Jane Cooper",
"displayEmail": "jane@example.com",
"displayUsername": "janecooper",
"humanityScore": 85,
"authenticityScore": 72,
"uniquenessScore": 91,
"behaviorScore": 68,
"createdAt": "2025-11-15T08:30:00Z",
"updatedAt": "2026-01-20T14:15:30Z",
"lastTrackedAt": "2026-01-20T14:15:30Z",
"lastScoredAt": "2026-01-20T14:15:32Z",
"disregarded": false,
"badges": [
{
"name": "Trusted User",
"type": "GOOD"
}
],
"data": {
"plan": "pro",
"company": "Acme Inc"
}
}
Scores
GET /api/identities/{id}/scores returns the four current category scores.
This is the cheap read, and it is the one most integrations want: it reports the
persisted scores without recomputing anything.
[
{"category": "HUMANITY", "value": 85},
{"category": "AUTHENTICITY", "value": 72},
{"category": "UNIQUENESS", "value": 91},
{"category": "BEHAVIOR", "value": 68}
]
Each value is an integer from 0 to 100. A category is omitted entirely
until the identity has been scored in that category, so an identity that has never
been analyzed returns an empty array.
Analysis with Observations
GET /api/identities/{id}/analysis returns the most recent analysis cycle,
including the individual analyzer observations that produced each score. Use this
endpoint when you need to see exactly why an identity received its scores. It returns
404 when the identity has not been analyzed yet.
{
"id": 2000871,
"identityId": "user_12345",
"scores": [
{
"category": "HUMANITY",
"value": 85,
"observations": [
{
"category": "HUMANITY",
"id": "humanity.user-agent",
"label": "User Agent Analysis",
"explanation": "Browser fingerprint consistent with standard Chrome on macOS",
"value": 0.92,
"confidence": 0.85,
"weight": 0.85,
"metadata": {
"browser": "Chrome",
"platform": "macOS",
"isHeadless": false
}
},
{
"category": "HUMANITY",
"id": "humanity.event-timing",
"label": "Event Timing Analysis",
"explanation": "Event intervals show natural human variation",
"value": 0.78,
"confidence": 0.72,
"weight": 0.72,
"metadata": {
"medianInterval": 4200,
"eventCount": 47
}
}
]
},
{"category": "AUTHENTICITY", "value": 72, "observations": [ ... ]},
{"category": "UNIQUENESS", "value": 91, "observations": [ ... ]},
{"category": "BEHAVIOR", "value": 68, "observations": [ ... ]}
],
"humanityScore": 85,
"authenticityScore": 72,
"uniquenessScore": 91,
"behaviorScore": 68,
"eventCount": 47,
"deviceCount": 2,
"durationMillis": 312,
"startedAt": "2026-09-21T14:22:09Z",
"finishedAt": "2026-09-21T14:22:09Z"
}
Each category’s value is an integer (0-100) computed as a weighted
average of its observations, with confidence as the weight. Observation
value and confidence are decimals between 0.0 and 1.0.
Paginated Lists
All list endpoints (GET /api/identities, GET /api/events,
GET /api/devices, etc.) return a consistent page structure:
{
"content": [ ... ],
"pageNumber": 0,
"pageSize": 25,
"totalElements": 1482,
"totalPages": 60
}
Interactive Documentation
The curated public API is an OpenAPI 3 document at
https://dregs.com/api/openapi.json.
It lists the operations you call with a secret key: events, identities, scores, devices,
escalations, badge rules, channels, datasets, mappings, and the dashboard summaries.
Each operation has an operationId, a description, and typed parameters and
responses. Authenticate with Authorization: Bearer sk_ followed by the secret
key from Settings → Credentials (OpenAPI scheme secretKey).
POST /api/events and GET /api/devices/{fingerprint} also accept
the public key (scheme publicKey, Bearer pk_).
That document is the customer API you call with your keys. It doesn't include dashboard sign-in, billing, team and credential management, or the trainer tools Dregs staff use, and the full internal specification isn't published. For help beyond the document, contact dregs@dregs.com.