Events And Killmails

Events

GET /v1/events
GET /v1/events/{id}

Events are public on-chain rows exported by Registry and indexed into D1.

Events are ordered newest first.

The event route is closest to raw source evidence. It is useful when you need to inspect a transaction, module, package id or payload shape.

Useful filters:

Parameter	Description
kind	Normalised event kind.
module	Move module name.
package_id	Sui package id.
transaction_digest	Sui transaction digest.
source_id	Registry source id.
environment	Defaults to stillness.
cycles	current or 6.

Example:

curl "https://api.blackrelay.network/v1/events?module=killmail&cycles=current&limit=20"

Windows:

Invoke-RestMethod "https://api.blackrelay.network/v1/events?module=killmail&cycles=current&limit=20"

Common module filters include:

Module	Typical Use
character	Character creation and identity evidence.
assembly	Smart Assembly creation evidence.
gate	Gate creation, linking and jump events.
storage_unit	Storage unit creation and inventory-related events.
turret	Turret creation and priority-list evidence.
network_node	Network-node creation and infrastructure context.
killmail	Killmail creation events.
inventory	Item mint, burn, deposit, withdraw and destruction events.
rift	Rift spawn and location broadcast events where indexed.

Event rows may contain raw numeric ids. Use entity, type, system and killmail routes to resolve names where the Registry has enough source context.

Killmails

GET /v1/killmails
GET /v1/killmails/{id}
GET /v1/killmails/{id}/raw

Killmail routes expose semantic combat records derived by Registry.

Killmails are ordered newest first.

Filters:

Parameter	Description
system	System entity id.
victim	Victim character entity id.
killer	Killer character entity id or explicit enemy static type id.
reporter	Reporter character entity id.
npc	true for NPC/enemy killmails, false for player-character killmails.
environment	Defaults to stillness.
cycles	current or 6.

Example:

curl "https://api.blackrelay.network/v1/killmails?npc=false&cycles=current&limit=20"

Windows:

Invoke-RestMethod "https://api.blackrelay.network/v1/killmails?npc=false&cycles=current&limit=20"

Killmail Shape

A resolved killmail can include:

Field	Meaning
id	Registry killmail id.
occurredAt	Event time in UTC.
systemId / systemName	System id and resolved display name where available.
victimCharacterId / victimName	Victim id and resolved name where available.
killerCharacterId / killerName	Killer id and resolved name where available.
reporterCharacterId / reporterName	Reporting character id and name where available.
summaryText	Human-readable summary generated by the API.
sourceIds	Source records supporting the killmail.
raw	Raw event context where available.

For example, a current player-character killmail can resolve to a summary such as:

Rain Nybom killed Stoika

That summary is derived from public chain event data plus Registry name resolution. Keep the raw ids available for drill-down.

NPC Resolution

Enemy names come from static-client evidence and reviewed extraction rules. NPC killmail resolution requires an explicit killer type id or a sourced enemy killer relation. Raw killer ids are not treated as static NPC type ids by default.

When an NPC killer is not proven, clients should display the semantic fields returned by the API and avoid inventing a name.

Event Versus Killmail Route

Use:

Need	Route
Show a combat table.	/v1/killmails
Show a single semantic combat record.	/v1/killmails/{id}
Inspect the raw event payload for a killmail.	/v1/killmails/{id}/raw or /v1/events?module=killmail
Debug a module-level event import.	/v1/events?module=<module>
Build an indexer-status page.	/v1/ops/freshness and /v1/ops/cursors

Do not rebuild killmail semantics in every client if the public killmail route already resolves the actors and system. Use raw events when you need source inspection or a fallback for fields the semantic route does not yet expose.