API documentation.

Lists accept page, per_page and search. Writes require a Read and write token. An instance’s sid is a 26-character ULID.

Supported map codes: chernarus, livonia, namalsk, sakhal, nasdara, deerisle, bitterroot, banov, deadfall, esseker, iztek, nyheim, valning, chernarusexp, livoniaexp, sakhalexp, alteria, anastara, antoria, arsteinen, avalon, azalea, channel, chernarus2035, chiemsee, deerisleexp, hashima, lux, malvinas, melkart, nhchernobyl, novikostok, nukezzone, onforin, pnw, pripyat, raman, ros, rostow, sahrani, siberia, stuartisland, takistanplus, vela, visisland, yiprit, varlind

curl --request POST "https://dzloggy.com/api/v1/instances" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json" \
  --header "Content-Type: application/json" \
  --data '{"name":"Chernarus EU","map":"chernarus","timezone":"Europe/London","description":"Community server"}'

curl --request PUT "https://dzloggy.com/api/v1/instances/INSTANCE_SID" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json" \
  --header "Content-Type: application/json" \
  --data '{"name":"Chernarus EU #1","map":"chernarus","description":"Updated community server"}'

Send name and map on every PUT. Keep any description you want to retain in the request. Your user API token remains separate from the ingestion key; see ingestion keys.

An ingestion key is the secret a DayZ server sends with Detailed Logs events. It is not your user API token, and you never choose it. DZLoggy generates a 64-character key and returns it once.

This does not affect servers that are already streaming. Existing keys keep working, and the endpoint the mod posts to is unchanged. Renaming an instance, changing its map or description, or editing its allowed IP addresses also leaves the key alone. Only a request that tries to supply its own stream_key is rejected.

curl --request POST "https://dzloggy.com/api/v1/instances" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json" \
  --header "Content-Type: application/json" \
  --data '{"name":"Chernarus EU","map":"chernarus","enabled_live_stream":true}'

{
  "data": { "sid": "01K7S8T9V0W1X2Y3Z4A5B6C7D8", "enabled_live_stream": true },
  "share_key": "SAVE_THE_RETURNED_SHARE_KEY",
  "stream_key": "SAVE_THIS_64_CHARACTER_KEY"
}

Save stream_key into the server’s ApiConfig.json straight away. Later responses never include it, and DZLoggy stores only its hash. A key is also created automatically the first time you enable streaming on an instance that does not have one.

curl --request PUT "https://dzloggy.com/api/v1/instances/INSTANCE_SID" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json" \
  --header "Content-Type: application/json" \
  --data '{"name":"Chernarus EU","map":"chernarus","regenerate_stream_key":true,"stream_address":"203.0.113.24"}'

Send stream_address again whenever you generate a key, including on creation. Omitting it allows any IP. A request that still sends stream_key returns 422 with the message "API keys are generated by DZLoggy. Send regenerate_stream_key instead.", whether or not that value matches an existing key. Generating a key requires the instance owner’s Plus or Pro plan.

{
  "data": {
    "sid": "01K7S8T9V0W1X2Y3Z4A5B6C7D8",
    "name": "Chernarus EU",
    "map": "chernarus",
    "timezone": "Europe/London",
    "description": "Community server",
    "enabled_live_stream": false,
    "is_owner": true,
    "created_at": "2026-10-15 00:00:00.000",
    "updated_at": "2026-10-15 00:00:00.000"
  },
  "share_key": "SAVE_THE_RETURNED_SHARE_KEY"
}

GET and PUT return the same data fields without share_key. The creation response also includes a Location header for the new resource. Save share_key if you want to invite members; it is distinct from both the user API token and the streaming key.

When POST or PUT generates an ingestion key, the response also includes stream_key, a 64-character secret shown only in that response. Save it in your server’s ApiConfig.json; DZLoggy stores only its hash.

curl --request DELETE "https://dzloggy.com/api/v1/instances/INSTANCE_SID" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json"

Archiving removes the instance and its data from accessible lists, disables live ingestion, invalidates its share key and revokes its instance ingestion keys. Existing stored evidence is retained; your account’s API token is not revoked.

A persistence scope identifies a generation of your server’s world. Use this endpoint when an upload belongs to a specific generation.

curl "https://dzloggy.com/api/v1/instances/INSTANCE_SID/persistence-scopes?per_page=50" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json"

{
  "id": "o1_SCOPE_TOKEN",
  "generation": 1,
  "name": null,
  "map": "chernarus",
  "opened_at": "2026-10-15 00:00:00.000",
  "closed_at": null
}

The example scope ID is abbreviated. Pass the actual returned id as persistence_scope when uploading logs to that same instance. If omitted, the latest open scope is selected; an instance with only closed scopes requires an explicit scope. Scopes are read-only through this API.

Returns the same snapshot as the Live Players page, built from Detailed Logs streaming events. Any member of the instance can read it with a read-only token. The instance owner needs a Pro plan; otherwise the response is 403.

curl "https://dzloggy.com/api/v1/instances/INSTANCE_SID/live-players" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --header "Accept: application/json"

{
  "data": {
    "instance": "01K7S8T9V0W1X2Y3Z4A5B6C7D8",
    "status": "live",
    "stream_enabled": true,
    "updated_at": "2026-10-15T12:00:00.000000Z",
    "last_observed_at": "2026-10-15T11:59:58.000000Z",
    "counts": { "active": 1, "disconnected": 0 },
    "limits": { "players": 500, "disconnected": 100, "events": 50 },
    "truncated": { "players": false, "disconnected": false, "events": false },
    "players": [{
      "sid": "01K7S8T9V0W1X2Y3Z4A5B6C7D9",
      "name": "Ranger",
      "steam_id": "76561198412934791",
      "connected_at": "2026-10-15T11:20:04.000000Z",
      "last_seen_at": "2026-10-15T11:59:58.000000Z",
      "position": { "x": 6512.4, "y": 12.1, "z": 2471.9 },
      "position_at": "2026-10-15T11:59:58.000000Z",
      "health": 100,
      "blood": 5000,
      "shock": 100
    }],
    "disconnected": [],
    "events": [{
      "id": "o1_EVENT_TOKEN",
      "log_file_sid": "01K7S8T9V0W1X2Y3Z4A5B6C7DA",
      "timestamp": "2026-10-15T11:59:58.000000Z",
      "event": "PLAYER_POSITION",
      "sub_event": "",
      "description": "Player position",
      "player": { "sid": "01K7S8T9V0W1X2Y3Z4A5B6C7D9", "name": "Ranger" }
    }]
  }
}

status is live when events arrived in the last 120 seconds, stale when the stream has gone quiet, waiting before the first streamed event, and disabled when streaming is off. Players are listed only while live. disconnected covers the last 30 minutes and adds disconnected_at; events covers the last 10 minutes, newest first. Position and vitals can be null until the server reports them. When truncated is true, counts still holds the full total.

Use a player sid with /api/v1/players/{sid}, and an event’s log_file_sid and id with /api/v1/logs/{sid}/events/{event} to fetch its details. This endpoint allows 60 requests per minute in addition to the shared account limit; polling every 10–15 seconds is plenty.