graph session object is a mutable property graph of vertices and edges. The envelope marks the
object as a graph and holds optional metadata about it; elements themselves live in a separate
element store managed by dedicated commands.
Envelope
Upload a graph envelope withupload_session_object, setting value.type to "graph":
graph object inside value carries two optional sub-fields:
The envelope is read back as-is via
download_session_object. No elements are included in that
response — elements are fetched exclusively through the graph commands.
Element Model
The graph stores two kinds of elements: vertices and edges.Vertex Fields
Edge Fields
Mutations
All writes go throughapply_session_graph_mutations, which accepts an ordered list of operations
applied atomically. A single call may contain at most 100 operations (subject to a server-enforced
action budget).
Optional field available on all mutation ops:
Optimistic Concurrency
Each element carries arev integer that increments on every successful mutation. To guard against
lost updates in concurrent environments, pass if_rev with the last-known rev of the element.
If the stored rev no longer matches, the entire batch is rejected with a graph_mutation_conflict
(HTTP 409) error and nothing is written.
Operations
All commands require the
alias of the graph envelope. If the envelope does not exist or its
value.type is not "graph", the server returns invalid_graph_envelope.
Events
After eachapply_session_graph_mutations call the server emits a
session_graph_changed event carrying the change
delta:
changes describes one logical effect of the batch:
The recommended client sync pattern is: apply
delete entries locally, then call
get_session_graph_elements with the element_id values from upsert entries to fetch their
updated state. For a full resync, use list_session_graph_elements with updated_since.
See also
- Session Objects — Introduction — envelope mechanics and the full list of session object types.
- Session Events — full event reference.

