Skip to main content
All CollectionsZapier/APIAPI
PracticePanther API
PracticePanther API

Using PracticePanther API.

PracticePanther Help Center avatar
Written by PracticePanther Help Center
Updated over 2 years ago

The PracticePanther API gives you access to all the features you see in our app and lets you extend them for use in your own app. It strives to be RESTful, supports OData Queries, and is organized around the main resources you’re familiar with from the PracticePanther web interface.

We’re big fans of KISS (keeping it stupid simple), and use the same approach for our backend.

API Basics


Before you do anything, you should create a PracticePanther account that you can test the API against.

IMPORTANT – The first step is to submit a request for API access so that you can make API calls.

Authentication (Authorize Endpoint)


The PracticePanther API uses OAuth 2 for authentication.
The URL of PracticePanther’s authorization page. This is the URL that your application should forward the user to in the first leg of OAuth 2.

Example Request

response_type (required)

  1. Whether the endpoint returns an authorization code. For web applications, a value of code should be used.

  2. Type: string

client_id (required)

  1. The client_id of your application, you can request one here.

  2. Type: string

redirect_uri (required)

  1. An HTTPS URI or custom URL scheme where the response will be redirected. Must be https and also be registered with the PracticePanther development team. In development, local http hosts are also accepted.

  2. Type: uri

state (required)

  1. An arbitrary string of your choosing that will be included in the response to your application. It is recommended that you create and include an anti-forgery token.

  2. Type: string

Example Request

HTTPS://YOUR_REDIRECT_URI?CODE=THE_AUTHORIZATION_CODE

Authentication (Token Endpoint)


The PracticePanther API uses OAuth 2 for authentication.

This is the endpoint that returns access tokens.

Example Request

grant_type (required)

  1. The grant type of this request. Will be authorization_code or refresh_token depending on which is accompanying this request

  2. Type: string

code

  1. An authorization code you retrieved in the first leg of OAuth 2

  2. Type: string

refresh_token

  1. A refresh token retrieved in the final leg of OAuth 2. In most cases these are valid for 60 days, or until used.

  2. Type: string

client_id (required)

  1. Your application’s client_id. You can request one here.

  2. Type: string

client_secret (required)

  1. Your application’s client_secret. You can request one here.

  2. Type: string

redirect_uri (required)

  1. Required to be configured within your application when access is provided to you.

expires_at

  1. A timestamp for when you want the Refresh Token to expire. Must be less than the default 60 days

  2. Type: unix timestamp

Swagger UI


Working with APIs is fun. That’s why we love Swagger UI. Swagger UI is the tool you see below that gives you full access to play with our API directly from your browser window. You can explore our entire API, see our models, methods and documentation, and even authenticate using OAuth 2.

Example Requests

Sample API calls are provided next to each method below using Swagger UI. All you need to do is drop in your specific parameters, and you can test the calls directly from this page. If the swagger UI is not your preference, a great alternative is POSTMAN, an easy-to-use Chrome extension for making HTTP requests.

Data Format

Both request body data and response data are formatted as JSON. Currency code are in ISO 4217 format and all date objects are in UTC.

ODATA Endpoints

All get list methods implement OData query endpoints to give you the flexibility to consume the data as you wish. This allows you to query the endpoint, filter, and order the data as you wish. For example:

GET api/TimeEntry/$count

GET api/TimeEntry?$orderby=date desc

GET api/TimeEntry?$filter=contains(user/name, ‘user@gmail.com’)

Fields

By default, each object has a standard, detailed, and reference formats.

  1. The standard format is returned when you make a request to receive a list of objects. For example /api/timeentry and will list basic information about each item.

  2. The detailed format is returned when you make a request to receive a single detailed item by Guid, for example, /api/timeentry/c23b7c9f-75c8-455a-9cd9-ec0cf4b332c3 and will include all available fields as well as summary fields. For example, the number of payments on an invoice, and the number of time entries for a matter.

  3. The reference format is returned when the object is referenced by another object. For example timeEntry.account will return an AccountRef object which will include the Guid and a string which usually represents the name of the object. To get the detailed object simply call the get endpoint for that object with the referenced Guid.

For more information about each object, click on one of the methods below, choose an action and click on the “Model” link next to the “Model Schema”. We are here if you have any questions. Click here to contact us, or submit a support request here.

Did this answer your question?