Get Transaction by ID

This guide walks you through retrieving the details of a specific eSignature transaction using the Stewart Sign API.

When to Use

Retrieving a transaction by ID is useful when you need to:

• Check the current status of a transaction (e.g., draft, esign_pending, completed, canceled)
• View participant details and signing progress
• Get document metadata associated with the transaction
• Verify transaction details before performing updates

Requirements

1. You need to have Node.js installed on your system.
2. You'll also need the axios library. You can install it using the following command:

npm install axios

3. A valid Bearer token (JWT) for authentication.
4. The transaction ID of the eSignature transaction you want to retrieve.

Endpoint

GET /transactions/{id}

Parameter	Type	Required	Description
id	string (UUID)	Yes	The unique identifier of the eSignature transaction.

Code Snippet

Use the following code snippet to retrieve a transaction by its ID. Replace <transactionId> with the actual transaction ID, and <accessToken> with your API access token.

const axios = require("axios");

const transactionId = "<transactionId>";

const config = {
  method: "get",
  url: `https://public-api.sign.stewart.com/transactions/${transactionId}`,
  headers: {
    Authorization: "Bearer <accessToken>",
  },
};

axios(config)
  .then(function (response) {
    console.log("Transaction retrieved successfully:", response.data);
  })
  .catch(function (error) {
    console.log(error.response?.data || error.message);
  });

Successful Response

On success, the API returns the full transaction object including documents, participants, and status:

{
  "id": "391866a6-8ebb-4533-b6ab-c7bb4d6fbd38",
  "status": "esign_pending",
  "documents": [
    {
      "id": "8d976a23-b865-4fcd-9165-ddc0aedaf614",
      "title": "Purchase Agreement",
      "sessionType": "esign"
    }
  ],
  "participants": [
    {
      "id": "37da192e-6420-4b9c-9951-a979eeaf8889",
      "email": "client@example.com",
      "firstName": "John",
      "lastName": "Doe"
    }
  ]
}

Error Responses

Status	Reason
401 Unauthorized	Invalid or expired Bearer token
404 Not Found	No transaction found with the provided ID

Steps to Execute the Code Snippet

1. Create a new file named get_transaction.js.
2. Copy and paste the code snippet provided above into the new file.
3. Replace <transactionId> and <accessToken> with the appropriate values.
4. Save the file and open a terminal or command prompt.
5. Navigate to the folder where you saved the get_transaction.js file.
6. Run the following command to execute the script:

node get_transaction.js

If the request is successful, you'll see the transaction details displayed in the console. In case of an error, the error details will be displayed instead.

V2-12387 — New response fields

The GET response now includes the following fields. All are optional except replyToOverriddenByBrand, which is always present.

Field	Type	Description
showConfetti	boolean	Whether a confetti animation plays for the signer after signing completes.
useReplyTo	boolean	Order-level setting: whether outgoing eSign emails include a Reply-To header. May be overridden by the brand — see below.
replyToEmail	string | null	Order-level Reply-To address stored on the eSign. May be overridden by the brand — see effectiveReplyTo.
replyToOverriddenByBrand	boolean	true when this transaction has a brandId whose brand has emailConfigEnabled and a resolved sender email — in which case the brand's Reply-To wins over the order-level Reply-To.
effectiveReplyTo	string | null	The Reply-To address that will actually be applied to outgoing emails, after the precedence: brand Reply-To > order-level Reply-To > null. null when useReplyTo is false and no brand override is active.
assignedGroupId	UUID | null	The team/group this transaction is assigned to, if any. Use GET /teams to discover IDs.
allowSignerNameEdit	boolean	Whether signers may edit their own name during the signing process.
fileReference	string | null	Initiator-supplied tracking identifier stored on the Transaction record.

Reply-To precedence

The same precedence applied by the email service when sending eSign emails is reflected in the response so you can show the user what will actually be used:

Scenario	replyToOverriddenByBrand	effectiveReplyTo
No brand, useReplyTo=true, replyToEmail set	false	replyToEmail value
Brand with emailConfigEnabled + resolved sender email	true	Brand's sender email
Brand with emailConfigEnabled + resolved sender email AND useReplyTo=true	true	Brand's sender email (brand wins)
Brand WITHOUT emailConfigEnabled, useReplyTo=true	false	replyToEmail value
No brand, useReplyTo=false	false	null

The order-level useReplyTo / replyToEmail values are still stored on the eSign record and returned by this endpoint, but they will NOT be applied to outgoing emails when the brand Reply-To is active. Always trust effectiveReplyTo for the actual outgoing behavior.

View-only participant fields

When a transaction includes a view-only recipient, that participant exposes the following additional fields in the participants array:

Field	Type	Description
role	string	"view-only" for view-only recipients (vs. "signer" / "non-signer" / a custom template role).
viewStatus	string	"pending" until the recipient first opens the documents, then "viewed".
viewedAt	string (ISO 8601) | null	Timestamp of the recipient's first view, or null if not yet viewed.

viewStatus and viewedAt are present only on view-only participants. See View-Only Recipients for the full request/response examples.

Additional Resources

For more information about the eSignature API, visit the API reference.

If you need further assistance or have questions, feel free to reach out to our support team.