Skip to main content
A 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 with upload_session_object, setting value.type to "graph":
The 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 through apply_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 a rev 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 each apply_session_graph_mutations call the server emits a session_graph_changed event carrying the change delta:
Each entry in 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