> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intavia.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# PPS setup

> Connect Intavia to PPS with the API token permissions needed for client lookup, availability, booking, rescheduling, and cancellation.

# PPS Integration Setup

## Required Permissions

Create a dedicated PPS API token for Intavia, then open **System Settings** -> **API** -> select the token -> **Edit Permissions**.

For full Intavia appointment automation, set these rows to the listed access level:

| Section  | Row              | Access     |
| -------- | ---------------- | ---------- |
| Client   | Detail           | Read/Write |
| Client   | Contact          | Read/Write |
| Diary    | Appointment      | Read/Write |
| Diary    | Appointment Type | Read       |
| Diary    | Availability     | Read       |
| User     | Practitioner     | Read       |
| User     | Location         | Read       |
| Location | -                | Read       |
| Clinic   | -                | Read       |

Add these only when your Intavia onboarding contact asks for them:

| Section | Row  | Access     | When needed                                      |
| ------- | ---- | ---------- | ------------------------------------------------ |
| Client  | Note | Read/Write | Writing call notes to PPS client records         |
| Diary   | RFNA | Read       | Validating PPS cancellation reasons during setup |

If PPS only lets you set a parent row, use the least parent permission that covers the child rows above: **Client: Read/Write**, **Diary: Read/Write**, **User: Read**, **Location: Read**, and **Clinic: Read**.

Do **not** grant **Read/Write/Delete**. Intavia cancels appointments by updating the appointment with the configured RFNA reason; it does not delete PPS clients, notes, or appointments.

If Intavia has asked for **client lookup only**, grant only: **Clinic: Read**, **Client -> Detail: Read**, **Client -> Contact: Read**, **Diary -> Appointment: Read**, and **Location: Read**.

If Intavia has asked for **availability checks only**, grant only: **Clinic: Read**, **Diary -> Appointment Type: Read**, **Diary -> Availability: Read**, **User -> Practitioner: Read**, **User -> Location: Read**, and **Location: Read**.

If Intavia has asked for **client lookup plus read-only availability access**, add **Client -> Detail: Read**, **Client -> Contact: Read**, and **Diary -> Appointment: Read**.

If your PPS permissions page has a separate **System** or **Main System Information** row, grant that row **Read** instead of **Clinic: Read**.

## Why These Permissions Are Needed

| Permission                            | What Intavia uses it for                                                               |
| ------------------------------------- | -------------------------------------------------------------------------------------- |
| Client Detail / Contact               | Find existing clients and create new client records with caller details.               |
| Diary Appointment                     | Read existing appointments, book, reschedule, and cancel appointments.                 |
| Diary Appointment Type / Availability | Read bookable appointment types and available time slots.                              |
| User Practitioner / User Location     | Show the right practitioners for the selected booking location.                        |
| Clinic or System information          | Validate the connection and read clinic opening-hours information when PPS exposes it. |

Leave all other sections unset unless Intavia explicitly asks for them. Intavia does not currently need **Medical History**, **Document**, **Activity**, **Audit**, **Accounts**, **User Access**, or **Read/Write/Delete** permissions.

If PPS shows appointment type profiles as a separate permission from **Diary -> Appointment Type**, grant appointment type profiles **Read** as well.

## Required Token Values

Copy these values from PPS into **Intavia** -> **Integrations** -> **PPS**:

| Intavia field   | Required?                                         |
| --------------- | ------------------------------------------------- |
| API Base URL    | Yes. Usually `https://pps-api.com`.               |
| System ID       | Yes                                               |
| Consumer Token  | Yes                                               |
| Consumer Secret | Yes                                               |
| Token           | Yes                                               |
| Token Secret    | Yes                                               |
| Login Token     | Optional. Leave blank unless Intavia asks for it. |

## Setup Steps

1. In PPS, create or open the API token you want Intavia to use.
2. Apply the permissions listed above and save the token.
3. Copy the token values.
4. In Intavia, open **Integrations** -> **PPS** -> **Connect**.
5. Paste the token values and click **Connect**.

## Additional Permissions Intavia May Request

Some future PPS rollouts may need extra read-only setup permissions, such as **Client -> Title**, **Client -> Intro Source**, **Department**, or **Room**, so Intavia can validate configured PPS IDs. Do not grant them unless your Intavia onboarding contact asks for them.

## Troubleshooting

### "Invalid PPS credentials"

Check the System ID, token values, and API Base URL. PPS token fields can be easy to copy with missing or extra characters.

### Availability is empty

Check **Diary -> Appointment Type: Read** and **Diary -> Availability: Read**. Also make sure the appointment types and availability you want Intavia to use are enabled for web/online booking in PPS.

### Booking or rescheduling fails

Check **Diary -> Appointment: Read/Write**. New-patient booking also needs **Client -> Detail: Read/Write** and **Client -> Contact: Read/Write**.

### Cancellation fails

Check **Diary -> Appointment: Read/Write**. Intavia also needs a configured RFNA reason for each cancellation reason it can use.

***

*Last Updated: June 2026*