---
title: API Documentation
description: "## Overview The PlanTRAK API provides read-only access to event data for integration into reporting, analytics, and business intelligence platforms such as Power BI, Qlik Sense, Tableau, Excel, or custom internal systems. Access to the API is restricted to authenticated…"
url: "https://www.solutionstrak.com/support/api-documentation/"
updated: "2026-07-22"
category: Admin
---

# API Documentation

## Overview

The PlanTRAK API provides read-only access to event data for integration into reporting, analytics, and business intelligence platforms such as Power BI, Qlik Sense, Tableau, Excel, or custom internal systems.

Access to the API is restricted to authenticated PlanTRAK clients. API Tokens are available only to Administrator-level users within the client portal.

# Authentication

The API uses Bearer Token authentication.

All API requests must include the following HTTP header:

```
Authorization: Bearer YOUR_API_TOKEN
```

## Important Notes

- API Tokens are generated per client organization.
- Tokens are available only to Administrator-level users.
- Regenerating a token immediately invalidates the previous token.
- Keep your API Token secure and do not share it outside your organization.
- All requests must use HTTPS.

# Base Endpoint

```
https://clients2.psaraonline.com/api/v1/analytics/events
```

# Available Endpoints

## **Open Events**

Returns events that are currently open, or active, and have not yet been closed.

### Endpoint

```
GET https://clients2.psaraonline.com/api/v1/analytics/events?type=open
```

 

## **Holding Table Events**

Returns events that have been closed by the facility, or submitted as completed, but are still awaiting review/approval.

### Endpoint

```
GET https://clients2.psaraonline.com/api/v1/analytics/events?type=holding
```

 

## **Recently Closed Events**

Returns events that have been fully approved and closed. An event will be returned if either its `close_date` or `approve_date` is within the requested `past_days` window, ensuring recently approved events are not missed even if they were originally closed outside the requested date range.

***Note:** For organizations that use the Holding Table workflow, the `recent_closed` endpoint returns events when either the `close_date` or `approve_date` falls within the requested `past_days` window. For organizations that do not use the Holding Table, `approve_date` will be `null`, and only `close_date` is used.*

### Endpoint

```
GET https://clients2.psaraonline.com/api/v1/analytics/events?type=recent_closed
```

### Optional Parameters

| Parameter | Description |
| --- | --- |
| `past_days` | Number of days back to retrieve recently closed events based on either the `close_date` or `approve_date`. |

### Parameter Rules

- Default: `3` days
- Maximum: `180` days

### Example

```
GET https://clients2.psaraonline.com/api/v1/analytics/events?type=recent_closed&past_days=30
```

#

# Event Lifecycle

| Status | is_closed | close_date | approve_date | Meaning |
| --- | --- | --- | --- | --- |
| Open | false | null | null | Event is active and has not been submitted (closed by the facility). |
| Holding Table | false | populated | null | Event has been submitted (closed by the facility) and is awaiting approval. |
| Recently Closed | true | populated | populated\* | Event has been approved and is fully closed. |

 

*Note: The `approve_date` field is only populated for organizations that use the Holding Table review workflow. For organizations that do not use the Holding Table, `approve_date` will remain `null`, and recently closed events are returned based on `close_date`.*

# Example API Requests

## Recently Closed Events

```
curl -X GET "https://clients2.psaraonline.com/api/v1/analytics/events?type=recent_closed&past_days=30" -H "Authorization: Bearer YOUR_API_TOKEN"
```

## Open Events

```
curl -X GET "https://clients2.psaraonline.com/api/v1/analytics/events?type=open" -H "Authorization: Bearer YOUR_API_TOKEN"
```

## Holding Table Events

```
curl -X GET "https://clients2.psaraonline.com/api/v1/analytics/events?type=holding" -H "Authorization: Bearer YOUR_API_TOKEN"
```

#

# Example Response

```
{
  "count": 462,
  "results": [
    {
      "area_id": 16,
      "area_name": "Other",
      "assignment_id": 2747,
      "assignment_name": "Albert Phillips",
      "citation": "",
      "citation_link": "N/A",
      "close_date": null,
      "approve_date": null,
      "comments": [],
      "due_date": "2028-03-29",
      "event_activity": "Quarterly Test",
      "event_description": "Testing",
      "event_id": 244822,
      "event_info": "",
      "event_parent_id": 14288,
      "event_parent_type": "Plan",
      "event_recommendation": null,
      "facility_id": 498,
      "facility_name": "Cincinnati, OH",
      "is_closed": false,
      "is_overdue": false,
      "is_regulatory": null,
      "required_checklist_id": null,
      "required_checklist_name": null,
      "requires_attachment": false,
      "type_id": 16,
      "type_name": "Other"
    },...
  ],
  "type": "open"
}
```

#

# Common Response Fields

| Field | Description |
| --- | --- |
| `event_id` | Unique event identifier |
| `facility_id` | Unique facility identifier |
| `facility_name` | Facility associated with the event |
| `area_id` | Unique area identifier |
| `area_name` | Environmental/compliance area |
| `assignment_id` | Unique identifier for the assigned user |
| `assignment_name` | Assigned user |
| `due_date` | Event due date |
| `close_date` | Date event was submitted/closed by the facility |
| `approve_date` | Date event was approved (if applicable) |
| `event_activity` | Event title/activity |
| `event_description` | Event description/details |
| `type_id` | Unique event type identifier |
| `type_name` | Event type |
| `is_closed` | Indicates final closure status |
| `is_overdue` | Indicates overdue status |
| `requires_attachment` | Indicates whether an attachment is required |

Some endpoints may also include additional comment-related or metadata fields.

#

# Recommended Synchronization Strategy

For most integrations, we recommend the following synchronization approach:

## Typical Daily Work Flow

- Pull Open Events.
- Pull Holding Table Events.
- Pull Recently Closed Events using a short rolling `past_days` window, such as 3 days.
  - *Provides overlap in case a scheduled refresh is delayed or fails.*
- Merge or update records using `event_id` as the unique identifier.

This approach helps ensure event updates are not missed while minimizing unnecessary or redundant data transfer.

#

# Rate Limiting

The API is designed for periodic synchronization and reporting workflows rather than continuous polling.

Daily refresh schedules are recommended for most integrations.