Docs
Community
What people say on Nostr about addresses, transactions and blocks: NIP-22 comments and NIP-32 labels indexed from our relay and the public relays, never endorsed by btcintel. The lens (labelers=) picks whose labels you see; zaps are a community signal, not an endorsement; the relay itself answers at GET /relay.
Generated from openapi.yaml (Btcintel native API 0.1.0). Every hash is canonical display order; every answer carries the index and node heights; errors use one envelope — see Semantics.
- GET
/relay— The embedded Nostr relay (WebSocket) and its NIP-11 document
GET /relay
The embedded Nostr relay (WebSocket) and its NIP-11 document
Spec S4.1: wss://relay.btcintel.io (Caddy rewrites the relay host to this path; wss://api.btcintel.io/relay is the same relay). A request with Upgrade: websocket opens the NIP-01 connection; Accept: application/nostr+json returns the NIP-11 information document (name, supported NIPs, limitations including the current min_pow_difficulty, posting_policy); any other GET answers a small JSON pointer with the relay URL, the posting policy, whether writes are open and the current proof-of-work floor. The door accepts kinds 1111 (NIP-22 comments), 1985 (NIP-32 labels) and 5 (NIP-09 deletions) that carry a NIP-73 bitcoin: subject and NIP-13 proof of work at or above the floor; it is read-only until the posting policy is signed off (S4.4). Reads serve only events this relay accepted, with the moderation lens applied. Not counted against tiers: the relay limits per pubkey (30 events / 10 min), per address (60 / 10 min) and per connection.
Response 200
The JSON pointer (or the NIP-11 document with Accept: application/nostr+json).
schema
relaystring — The public wss:// URL.nip11stringposting_policystring (uri)write_enabledbooleanmin_pow_difficultyintegeraccepted_kindsarray of integer
Errors
429— Too many new connections from this address (WebSocket upgrades only).
Example
curl -s https://api.btcintel.io/relay | jq '{relay, nip11, posting_policy}'