Skip to main content
When a metagraph implements a data application, the Currency L1 node exposes additional HTTP endpoints for submitting and querying custom DataUpdate objects. These endpoints are only available on metagraphs that have the dataApplication extension point configured.
All endpoints return the following response headers:
  • X-Id — The node’s public key identifier
  • X-Session-Token — The current cluster session token
  • Request-Signature — Cryptographic signature of the response for verification
The data application routes are served on a separate Data L1 node instance (distinct from the Currency L1 node). The default port for data application endpoints is typically 9400.

​
GET /data

Returns the list of DataUpdate objects currently enqueued for processing in the next consensus round. 
curl https://<metagraph-data-l1-host>:9400/data
Response 200 OK — Array of signed data update objects awaiting inclusion
​
[]
array
Array of SignedDataUpdate objects

​
POST /data

Submits a signed custom data update object for processing. The data update is validated by the metagraph’s validateUpdate implementation and, if accepted, forwarded to the L0 for inclusion in the next currency snapshot. 
curl -X POST https://<metagraph-data-l1-host>:9400/data \
  -H "Content-Type: application/json" \
  -d '{
    "value": {
      "customField": "customValue"
    },
    "proofs": [
      { "id": "<public-key-hex>", "signature": "<ecdsa-der-hex>" }
    ]
  }'
​
value
object
required
The custom data update payload. The schema is defined by the metagraph’s data application. Must be serializable as JSON and compatible with the metagraph’s DataUpdate type.
​
proofs
array
required
Array of cryptographic signature proofs
Response 200 OK
​
hash
string
Hash of the accepted data update object
Response 400 Bad Request — Invalid data update or signature. The metagraph’s validateUpdate rejected the submission.
​
message
string
Human-readable rejection reason from the metagraph’s validator
Response 503 Service Unavailable — Last global snapshot ordinal is not yet available. The node is still syncing.

​
Data flow

Data updates submitted to /data follow this lifecycle:
  1. L1 node calls validateUpdate — if rejected, returns 400
  2. Accepted updates are held in the mempool
  3. During next consensus round, updates are batched into a DataApplicationBlock
  4. Block is sent to the Currency L0 node
  5. L0 calls validateData and combine — updates are merged into DataState
  6. Final state is included in the CurrencyIncrementalSnapshot
  7. onSnapshotConsensusResult is called after finalization
See Data applications for guidance on implementing the DataUpdate schema and validation logic.

Build docs developers (and LLMs) love

Get started for freeTalk to us