API reference
Base URL, authentication, pagination, errors and rate limits of the dlogify API.
This page covers what every endpoint has in common. The pages under it describe each operation, generated from the same contract the API is built from.
Base URL
https://api.dlogify.comEvery endpoint lives under /v1/. The machine-readable contract (OpenAPI 3.1) is served at GET /v1/openapi.json; use it to generate a client.
Authentication
The API accepts two kinds of credentials, and each endpoint takes exactly one of them.
| Credential | Header | Endpoints |
|---|---|---|
| Project API key | Authorization: Bearer lgf_live_<key_id>_<secret> | Ingestion only: POST /v1/ingest, POST /v1/logs and OTLP/gRPC |
| Session token | Authorization: Bearer <session token> | Everything else: organizations, projects, keys, channels, tickets, groups |
Sending an API key to a management endpoint, or a session token to an ingestion endpoint, returns 401 unauthorized: it is the wrong kind of credential, not a missing permission.
Get a session token for scripts
Sign in with the email and password of your dlogify account. The response carries the token:
curl -s https://api.dlogify.com/v1/auth/sign-in/email \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]", "password": "your-password"}'{ "token": "0f3c…", "user": { "id": "usr_01j…", "email": "[email protected]", "…": "…" } }Send it as a bearer token on management requests, and end the session when you are done:
curl -s https://api.dlogify.com/v1/orgs -H "Authorization: Bearer $DLOGIFY_SESSION"
curl -s -X POST https://api.dlogify.com/v1/auth/sign-out -H "Authorization: Bearer $DLOGIFY_SESSION"The web app at dlogify.com uses a session cookie instead. A cookie-authenticated change that does not come from the web app is rejected with 403 csrf-origin-rejected; scripts should always use the bearer token.
Roles
Management endpoints also check your role in the organization. Each operation page states the minimum role it needs ("Requires role member or higher"). A role that is too low returns 403 forbidden.
Pagination
Lists are paginated with a cursor:
GET /v1/projects/prj_01j…/tickets?limit=50&cursor=…limit defaults to 50 and is at most 100. The response holds one page and the cursor of the next one, which is null on the last page:
{ "data": [ { "id": "tkt_01j…", "…": "…" } ], "next_cursor": "eyJ…" }Pass next_cursor back as cursor to read the next page. Cursors are opaque: do not build or change them.
Conventions
- JSON bodies with
snake_casefields. - Timestamps in UTC, ISO 8601 (
2026-10-03T14:03:11.482Z). - IDs are prefixed and opaque:
org_…(organization),prj_…(project),key_…(API key),usr_…(user),mem_…(member),inv_…(invitation),chn_…(channel),grp_…(error group),tkt_…(ticket).
Errors
Errors are RFC 9457 problems with the content type application/problem+json:
{
"type": "https://docs.dlogify.com/errors/rate-limited",
"title": "Too many requests",
"status": 429,
"detail": "Organization org_01j… exceeded 1000 events/min.",
"instance": "req_01j…"
}type is the address of the page that explains the error. Switch on type in your code, not on title or detail. The full list is in Errors.
Rate limits
Responses carry RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset. When a limit is hit the API answers 429 rate-limited with a Retry-After header: wait that many seconds and send the same request again.
Versioning
/v1/ is stable. New endpoints and new response fields can appear at any time, so ignore fields you do not know. A breaking change would ship as /v2/.