The Neo4j Manual v2.0.319.1. Transactional HTTP endpoint

You begin a new transaction by posting zero or more Cypher statements to the transaction endpoint. The server will respond with the result of your statements, as well as the location of your open transaction.

Example request

{
  "statements" : [ {
    "statement" : "CREATE (n {props}) RETURN n",
    "parameters" : {
      "props" : {
        "name" : "My Node"
      }
    }
  } ]
}

Example response

{
  "commit" : "http://localhost:7474/db/data/transaction/7/commit",
  "results" : [ {
    "columns" : [ "n" ],
    "data" : [ {
      "row" : [ {
        "name" : "My Node"
      } ]
    } ]
  } ],
  "transaction" : {
    "expires" : "Wed, 30 Apr 2014 10:31:42 +0000"
  },
  "errors" : [ ]
}

Given that you have an open transaction, you can make a number of requests, each of which executes additional statements, and keeps the transaction open by resetting the transaction timeout.

Example request

{
  "statements" : [ {
    "statement" : "CREATE n RETURN n"
  } ]
}

Example response

{
  "commit" : "http://localhost:7474/db/data/transaction/9/commit",
  "results" : [ {
    "columns" : [ "n" ],
    "data" : [ {
      "row" : [ {
      } ]
    } ]
  } ],
  "transaction" : {
    "expires" : "Wed, 30 Apr 2014 10:31:42 +0000"
  },
  "errors" : [ ]
}

Given that you have an open transaction, you can make a number of requests, each of which executes additional statements, and keeps the transaction open by resetting the transaction timeout. Specifying the REST format will give back full Neo4j Rest API representations of the Neo4j Nodes, Relationships and Paths, if returned.

Example request

{
  "statements" : [ {
    "statement" : "CREATE n RETURN n",
    "resultDataContents" : [ "REST" ]
  } ]
}

Example response

{
  "commit" : "http://localhost:7474/db/data/transaction/1/commit",
  "results" : [ {
    "columns" : [ "n" ],
    "data" : [ {
      "rest" : [ {
        "labels" : "http://localhost:7474/db/data/node/0/labels",
        "outgoing_relationships" : "http://localhost:7474/db/data/node/0/relationships/out",
        "all_typed_relationships" : "http://localhost:7474/db/data/node/0/relationships/all/{-list|&|types}",
        "traverse" : "http://localhost:7474/db/data/node/0/traverse/{returnType}",
        "self" : "http://localhost:7474/db/data/node/0",
        "property" : "http://localhost:7474/db/data/node/0/properties/{key}",
        "outgoing_typed_relationships" : "http://localhost:7474/db/data/node/0/relationships/out/{-list|&|types}",
        "properties" : "http://localhost:7474/db/data/node/0/properties",
        "incoming_relationships" : "http://localhost:7474/db/data/node/0/relationships/in",
        "create_relationship" : "http://localhost:7474/db/data/node/0/relationships",
        "paged_traverse" : "http://localhost:7474/db/data/node/0/paged/traverse/{returnType}{?pageSize,leaseTime}",
        "all_relationships" : "http://localhost:7474/db/data/node/0/relationships/all",
        "incoming_typed_relationships" : "http://localhost:7474/db/data/node/0/relationships/in/{-list|&|types}",
        "data" : {
        }
      } ]
    } ]
  } ],
  "transaction" : {
    "expires" : "Wed, 30 Apr 2014 10:31:38 +0000"
  },
  "errors" : [ ]
}

Every orphaned transaction is automatically expired after a period of inactivity. This may be prevented by resetting the transaction timeout.

The timeout may be reset by sending a keep-alive request to the server that executes an empty list of statements. This request will reset the transaction timeout and return the new time at which the transaction will expire as an RFC1123 formatted timestamp value in the “transaction” section of the response.

Example request

{
  "statements" : [ ]
}

Example response

{
  "commit" : "http://localhost:7474/db/data/transaction/2/commit",
  "results" : [ ],
  "transaction" : {
    "expires" : "Wed, 30 Apr 2014 10:31:41 +0000"
  },
  "errors" : [ ]
}

Given you have an open transaction, you can send a commit request. Optionally, you submit additional statements along with the request that will be executed before committing the transaction.

Example request

{
  "statements" : [ {
    "statement" : "CREATE n RETURN id(n)"
  } ]
}

Example response

{
  "results" : [ {
    "columns" : [ "id(n)" ],
    "data" : [ {
      "row" : [ 2 ]
    } ]
  } ],
  "errors" : [ ]
}

Given that you have an open transaction, you can send a roll back request. The server will roll back the transaction.

Example request

Example response

{
  "results" : [ ],
  "errors" : [ ]
}

If there is no need to keep a transaction open across multiple HTTP requests, you can begin a transaction, execute statements, and commit with just a single HTTP request.

Example request

{
  "statements" : [ {
    "statement" : "CREATE n RETURN id(n)"
  } ]
}

Example response

{
  "results" : [ {
    "columns" : [ "id(n)" ],
    "data" : [ {
      "row" : [ 3 ]
    } ]
  } ],
  "errors" : [ ]
}

If you want to understand the graph structure of nodes and relationships returned by your query, you can specify the "graph" results data format. For example, this is useful when you want to visualise the graph structure. The format collates all the nodes and relationships from all columns of the result, and also flattens collections of nodes and relationships, including paths.

Example request

{
  "statements" : [ {
    "statement" : "CREATE ( bike:Bike { weight: 10 } )CREATE ( frontWheel:Wheel { spokes: 3 } )CREATE ( backWheel:Wheel { spokes: 32 } )CREATE p1 = bike -[:HAS { position: 1 } ]-> frontWheel CREATE p2 = bike -[:HAS { position: 2 } ]-> backWheel RETURN bike, p1, p2",
    "resultDataContents" : [ "row", "graph" ]
  } ]
}

Example response

{
  "results" : [ {
    "columns" : [ "bike", "p1", "p2" ],
    "data" : [ {
      "row" : [ {
        "weight" : 10
      }, [ {
        "weight" : 10
      }, {
        "position" : 1
      }, {
        "spokes" : 3
      } ], [ {
        "weight" : 10
      }, {
        "position" : 2
      }, {
        "spokes" : 32
      } ] ],
      "graph" : {
        "nodes" : [ {
          "id" : "4",
          "labels" : [ "Bike" ],
          "properties" : {
            "weight" : 10
          }
        }, {
          "id" : "5",
          "labels" : [ "Wheel" ],
          "properties" : {
            "spokes" : 3
          }
        }, {
          "id" : "6",
          "labels" : [ "Wheel" ],
          "properties" : {
            "spokes" : 32
          }
        } ],
        "relationships" : [ {
          "id" : "0",
          "type" : "HAS",
          "startNode" : "4",
          "endNode" : "5",
          "properties" : {
            "position" : 1
          }
        }, {
          "id" : "1",
          "type" : "HAS",
          "startNode" : "4",
          "endNode" : "6",
          "properties" : {
            "position" : 2
          }
        } ]
      }
    } ]
  } ],
  "errors" : [ ]
}

The result of any request against the transaction endpoint is streamed back to the client. Therefore the server does not know whether the request will be successful or not when it sends the HTTP status code.

Because of this, all requests against the transactional endpoint will return 200 or 201 status code, regardless of whether statements were successfully executed. At the end of the response payload, the server includes a list of errors that occurred while executing statements. If this list is empty, the request completed successfully.

If any errors occur while executing statements, the server will roll back the transaction.

In this example, we send the server an invalid statement to demonstrate error handling.

For more information on the status codes, see Section 19.2, “Neo4j Status Codes”.

Example request

{
  "statements" : [ {
    "statement" : "This is not a valid Cypher Statement."
  } ]
}

Example response

{
  "results" : [ ],
  "errors" : [ {
    "code" : "Neo.ClientError.Statement.InvalidSyntax",
    "message" : "Invalid input 'T': expected <init> (line 1, column 1)\n\"This is not a valid Cypher Statement.\"\n ^"
  } ]
}