Reliable Nostr Relay Intelligence
Access relay health, availability, and connectivity metadata through a lightweight, Bitcoin-funded API. No subscription traps. No credit card records.
Evaluate data feeds integration before committing resources.
- 100 API requests / day
- Limited relay records
- Basic telemetry (Uptime)
- No historical archives
Perfect for indie builders, clients, and custom directory integration.
- 10,000 API requests / day
- Full relay database access
- High-resolution health metrics
- Daily updates & indices
For enterprise-grade clients needing rapid historical health monitoring.
- 100,000 API requests / day
- Hourly state synchronization
- Advanced geo/NIP query filtering
- Bulk raw data CSV/JSON exports
API Sandbox & Reference
Query active Nostr relays directly with our clean database format schemas.
curl -X GET "https://nostrwat.ch/relays?limit=3" \ -H "Authorization: Bearer nw_live_your_key_here"
{
"status": "success",
"endpoint": "/relays",
"relays": [
{
"name": "relay.damus.io",
"addr": "relay.damus.io",
"ipv4": "185.123.45.67",
"port": 443,
"protocol": "wss",
"first": 1749600000,
"last": 1749686400,
"success": 4312,
"health": "Functioning"
},
{
"name": "nos.lol",
"addr": "nos.lol",
"ipv4": "95.217.151.102",
"port": 443,
"protocol": "wss",
"first": 1749601000,
"last": 1749686400,
"success": 4192,
"health": "Functioning"
}
]
}
API Keys Management Locked
Authenticate using your Nostr client/extension to view, generate, and revoke access credentials for your projects.
API Token Console
Manage API credentials assigned to your pubkey:
Credentials Directory
Each credential runs on its specific tier and active check limitsHow API credentials correlate in the database
To maintain sovereignty and compliance with standard API design parameters, here is how client metadata keys map directly against standard database schemas in our backend layer:
CREATE TABLE api_keys (
id INT AUTO_INCREMENT PRIMARY KEY,
pubkey VARCHAR(64) NOT NULL, # Hex format Nostr public key
api_key VARCHAR(64) UNIQUE NOT NULL, # Secret hash reference (nw_live_...)
label VARCHAR(255) NOT NULL, # User-supplied identifier
tier VARCHAR(32) DEFAULT 'free', # free | basic | pro
active TINYINT DEFAULT 1 # 1 = active, 0 = inactive
);
How to measure latency and parse telemetry?
Implementation examples using native HTML5 WebSockets and math reconstruction logic.
Method 1 Active WebSocket Latency Measurement
Because Nostr relays operate asynchronously on WebSockets, measuring the round-trip handshake time directly in the client is the best approach:
// Measures Nostr relay latency in client applications via native WebSockets
function measureRelayHandshake(relayUrl) {
return new Promise((resolve, reject) => {
// High-precision clock microsecond timestamp
const startTime = performance.now();
let socket;
const timeout = setTimeout(() => {
if (socket) socket.close();
reject(new Error("Timeout (Handshake limit reached)"));
}, 3000);
try {
socket = new WebSocket(relayUrl);
socket.onopen = () => {
clearTimeout(timeout);
const latency = performance.now() - startTime;
socket.close();
resolve(Math.round(latency));
};
socket.onerror = (err) => {
clearTimeout(timeout);
reject(err);
};
} catch (error) {
clearTimeout(timeout);
reject(error);
}
});
}
Method 2 Reconstructing Global Monitoring Metrics from DB Model
Parse the compressed database payload to reconstruct denominator metrics without bloated row tracking:
// Reconstructs denominator metadata using standard successes and health floats
function decodeTelemetry(relayObject) {
const success = relayObject.success;
const health = relayObject.health;
// Avoid division by zero
if (health === 0) {
return { total_checks: 0, failed_checks: success };
}
// Calculate back total global checkpoints in this cycle
const total_checks = Math.round(success / (health / 100));
const failed_checks = total_checks - success;
return {
total_checks,
failed_checks,
health: parseFloat(health.toFixed(4))
};
}