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.