Transaction Jobs

Transaction Jobs run transaction exports asynchronously so your integration is not blocked by long-running queries. Instead of waiting for a synchronous response that might time out on a large portfolio, you submit a job, poll for completion, and download the results when ready. Results remain available for 24 hours after job creation.

Transaction Jobs support two modes: view jobs export a saved transaction view as CSV, TSV, or XLSX; query jobs execute an ad-hoc transaction query and return JSON. Both modes accept the same portfolio scoping parameters (entity, group, or firm-wide) and date range filters.

When to use Transaction Jobs

Use Transaction Jobs instead of the synchronous Transactions or Transactions Query endpoints when:

• The portfolio contains thousands of transactions and a synchronous request risks timing out
• You need file-format output (CSV, TSV, XLSX) for downstream systems
• Your integration processes transaction data on a schedule and can tolerate async delivery
• You want to avoid consuming rate limit budget during the processing phase (polling is lightweight)

For small, targeted transaction retrieval (single entity, narrow date range), the synchronous Transactions Query endpoint is simpler and returns immediately.

Overview

📘

Access requirements

API Access: Create, edit, and delete.
Portfolio Access: Required to view the transaction data being exported.
OAuth scope: TRANSACTIONS

Resource attributes

Every GET and POST response returns these attributes on the job resource:

Job statuses

Job parameters

Create a transaction view job

Exports a saved transaction view as a file. The view defines the columns, filters, and sorting; you provide the portfolio scope and date range.

POST /v1/transaction_jobs

curl -X POST "https://{firm}.addepar.com/api/v1/transaction_jobs" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/vnd.api+json" \
  -d '{
    "data": {
      "type": "transaction_jobs",
      "attributes": {
        "job_type": "transaction_view_results",
        "parameters": {
          "view_id": 5,
          "portfolio_id": 193,
          "portfolio_type": "entity",
          "output_type": "xlsx",
          "start_date": "2024-01-01",
          "end_date": "2024-06-30"
        }
      }
    }
  }'

{
  "data": {
    "id": "47d7e547-7f5a-11ef-8162-dde0088e926a",
    "type": "transaction_jobs",
    "attributes": {
      "job_type": "TRANSACTION_VIEW_RESULTS",
      "percent_complete": 0.0,
      "status": "Queued"
    },
    "relationships": {
      "creator": {
        "links": {
          "self": "/v1/transaction_jobs/47d7e547-7f5a-11ef-8162-dde0088e926a/relationships/creator",
          "related": "/v1/transaction_jobs/47d7e547-7f5a-11ef-8162-dde0088e926a/creator"
        },
        "data": { "type": "users", "id": "22" }
      }
    },
    "links": {
      "self": "/v1/transaction_jobs/47d7e547-7f5a-11ef-8162-dde0088e926a"
    }
  },
  "included": []
}

Create a transaction query job

Runs an ad-hoc query against transaction data. You define columns, filters, and sorting inline rather than referencing a saved view.

POST /v1/transaction_jobs

curl -X POST "https://{firm}.addepar.com/api/v1/transaction_jobs" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/vnd.api+json" \
  -d '{
    "data": {
      "type": "transaction_jobs",
      "attributes": {
        "job_type": "transaction_query",
        "parameters": {
          "columns": [
            "trade_date",
            "direct_owner",
            "security",
            "type",
            "value",
            "last_edit_by",
            "last_edit_date"
          ],
          "filters": [],
          "sorting": [],
          "portfolio_type": "entity",
          "portfolio_id": [12345],
          "start_date": "2024-08-03",
          "end_date": "2024-09-03",
          "include_online_valuations": false,
          "include_unverified": false,
          "include_deleted": true
        }
      }
    }
  }'

{
  "data": {
    "id": "204da3ed-7de0-11ef-99fa-25422e3df74b",
    "type": "transaction_jobs",
    "attributes": {
      "job_type": "TRANSACTION_QUERY",
      "percent_complete": 0.0,
      "status": "Queued"
    },
    "relationships": {
      "creator": {
        "links": {
          "self": "/v1/transaction_jobs/204da3ed-7de0-11ef-99fa-25422e3df74b/relationships/creator",
          "related": "/v1/transaction_jobs/204da3ed-7de0-11ef-99fa-25422e3df74b/creator"
        },
        "data": { "type": "users", "id": "1000314556" }
      }
    },
    "links": {
      "self": "/v1/transaction_jobs/204da3ed-7de0-11ef-99fa-25422e3df74b"
    }
  },
  "included": []
}

Response codes (both job types):

• 202 Accepted -- Job created and queued
• 400 Bad Request -- Invalid JSON, missing required parameters, or bad format
• 403 Forbidden -- Insufficient permissions or scope

Check job status

GET /v1/transaction_jobs/:id

Returns the current status and progress of a specific job. Poll this endpoint until status is Completed, Failed, or another terminal state.

curl -X GET "https://{firm}.addepar.com/api/v1/transaction_jobs/39cee0a7-7f5d-11ef-a01d-45a1a34a1c7c" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Accept: application/vnd.api+json"

{
  "data": {
    "id": "39cee0a7-7f5d-11ef-a01d-45a1a34a1c7c",
    "type": "transaction_jobs",
    "attributes": {
      "job_type": "TRANSACTION_QUERY",
      "percent_complete": 0.21,
      "status": "In Progress"
    },
    "relationships": {
      "creator": {
        "links": {
          "self": "/v1/transaction_jobs/39cee0a7-7f5d-11ef-a01d-45a1a34a1c7c/relationships/creator",
          "related": "/v1/transaction_jobs/39cee0a7-7f5d-11ef-a01d-45a1a34a1c7c/creator"
        },
        "data": { "type": "users", "id": "22" }
      }
    },
    "links": {
      "self": "/v1/transaction_jobs/39cee0a7-7f5d-11ef-a01d-45a1a34a1c7c"
    }
  },
  "included": []
}

Response codes:

• 200 OK -- Job found
• 403 Forbidden -- Insufficient permissions
• 404 Not Found -- Job does not exist or not accessible

List all jobs

GET /v1/transaction_jobs

Returns all transaction jobs visible to the authenticated user.

curl -X GET "https://{firm}.addepar.com/api/v1/transaction_jobs" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Accept: application/vnd.api+json"

The response contains an array of job resources with status, timestamps, and creator relationships.

Response codes:

• 200 OK -- Success
• 403 Forbidden -- Insufficient permissions

Download results

GET /v1/transaction_jobs/:id/download

If the job is complete, returns the file content (for view jobs) or JSON results (for query jobs). If the job is still running, returns the current status payload instead.

curl -X GET "https://{firm}.addepar.com/api/v1/transaction_jobs/657c5d9b-7f5d-11ef-a01d-2900745d31ff/download" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Accept: application/vnd.api+json"

For completed view jobs, the response includes a Content-Disposition header with the filename and the binary file content.

Response codes:

• 200 OK -- Results returned inline
• 303 See Other -- Follow the Location header to retrieve results
• 404 Not Found -- Job does not exist
• 410 Gone -- Results expired (24-hour retention window passed)

Cancel a job

DELETE /v1/transaction_jobs/:id

Cancels a job regardless of its current state:

curl -X DELETE "https://{firm}.addepar.com/api/v1/transaction_jobs/39cee0a7-7f5d-11ef-a01d-45a1a34a1c7c" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Accept: application/vnd.api+json"

204 No Content

Response codes:

• 204 No Content -- Cancel submitted
• 404 Not Found -- Job does not exist or not accessible

Polling pattern

A typical integration follows this lifecycle:

1. POST to create the job. Receive 202 Accepted with the job ID.
2. GET /v1/transaction_jobs/:id every 5-10 seconds. Check percent_complete and status.
3. When status is Completed, GET /v1/transaction_jobs/:id/download to retrieve results.
4. If status is Failed, Rejected, or Error Cancelled, read the errors field and decide whether to retry.

Polling does not consume rate limit budget at the same rate as data-fetching endpoints, so frequent polling (every 5 seconds) is acceptable for time-sensitive integrations.

Relationship endpoints

📘

Related

• Transactions -- Synchronous transaction CRUD (up to 500 per request)
• Transactions Query -- Synchronous filtered transaction retrieval
• Transaction Types -- Valid transaction type classifications
• Jobs -- General async job pattern (portfolio queries, reports)
• Rate Limiting -- How polling fits into your rate budget