Skip to main content

​
API overview

The PressChain API repository is intended to own REST and streaming interfaces, authentication, authorization, scopes, quotas, service accounts, metering, billing events and webhooks. The currently implemented Rust binary is deliberately narrower than that long-term surface. Today, the implemented binary is read-only and exposes health plus bounty proposal and evaluation reads from the configured bounty-engine state directory. That distinction matters. These docs do not invent Capsule REST writes or present planned endpoints as deployed features.

​
Current routes

Unknown write methods return 405 method_not_allowed. Unknown read routes return 404 route_not_found.

​
Runtime configuration

The binary reads its listening port from:
with default 46331. Bounty state is read from:
with default /var/lib/presschain/bounty-engine-rust. The service binds to IPv4 localhost by default. In production, expose it through controlled infrastructure rather than assuming the process itself should listen on every network interface.

​
Read convenience versus protocol authority

An HTTP API can make a product easier to build, but it is not a substitute for chain authority. A projected response should be traceable to the underlying protocol state where the data is canonical. For current user-authorized writes, applications should use active contract ABIs and PressKey rather than invent a server transaction relay. A practical application flow is:
  1. read current Capsule state from RPC or a projection
  2. prepare metadata or evidence in the application backend
  3. compute canonical hashes
  4. return transaction intent to the browser
  5. authorize through PressKey
  6. observe the resulting transaction and event
  7. update the read model
The user signer remains at the user boundary.

​
Planned API ownership

The repository architecture reserves room for authenticated and premium APIs, scopes, keys, metering and webhooks. A planned capability belongs in architecture documentation until its route and deployment are source-backed. This prevents developers from debugging nonexistent endpoints.

​
API version versus protocol version

The HTTP namespace currently uses /v1/. That does not mean the blockchain protocol is V1. API version and protocol major are separate compatibility domains. A V1 HTTP response can expose V3 protocol records as long as its own response contract remains stable.

​
Design guidance for new APIs

Future endpoints should preserve canonical identifiers exactly, expose source provenance for projected data and avoid moving signing authority into the API layer. Write preparation, validation and transaction simulation can be excellent server features without turning the server into the owner of a user key.