Sikka APIs

Sikka Platform Cloud provides APIs so you can quickly build secure apps for over 96 % of dental, veterinary, audiology and optometry industries.Use our API to gain access to all the opt - in HIPAA / HITECH compliant rich data that a healthcare practice generates.

Join our Ecosystem and build your own Apps!The Sikka Ecosystem harnesses the power of over 36 unique apps for you to gain full control of your practice, while viewing real - time industry metrics, securely - all at your fingertips! Visit : Sikka Marketplace

Getting Started

Welcome to Sikka API. Here you will find the step-by-step guide that will help you build an application on the Sikka Platform and full listing of all the available APIs. As we add more APIs, they will automatically documented here and available to you as per your API plan. For more information about a particular endpoint, click on its name. You will be taken to the API’s documentation page, which includes what query parameters the API will accept, what the JSON or XML parameters will be in the response, and an example.

Follow Below Steps
  • Step 1 : Register an app with Sikka
  • Step 2 : Add clients to your app
  • Step 3 : Get an authorization
  • Step 4 : Install SPC (Sikka Platform Cloud)
  • Step 5 : Fetching and displaying data
What developers need to do?

What your clients need to do to display data?

Prerequisite

To fetch the data you will need to add practice to your app. SPC (Sikka Platform Cloud) must be installed on practice to fetch the data.

Step 1 : Register an app with Sikka

Register an App with Sikka

Please provide all necessary information about your App. It will help us to authorize your app.

After successful App registration you will get an application id and application key. Keep these keys safe as it will require to fetch the data from practice.

Note : Do not disclose your keys.

Step 2 : Add clients to your app

Contact sikka software API team for detail information.

Step 3 : Get an authorization

We do support oAuth 2.0

oAuth 2.0 is a protocol that lets your app access the practice details in a Sikka account without getting their password.

You'll need to register your app before getting started. A registered app is assigned a unique Application ID (Client ID) and Application Secret Key (Client Secret) which will be used in the OAuth flow. The Application ID and Application Secret Key should not be shared.

Sign in with Sikka ( You will find the url in API portal, under 'Application Details' as 'authorization link') is the best way to log individual user into your application.

The oAuth Flow
Step 1 - Authorization

Your web or mobile app should redirect users to the following URL:

https://api.sikkasoft.com/portal/authapp.aspx?response_type=code&client_id=APPLICATION_ID&redirect_uri=REDIRECT_URI&scope=*&state=123456

The following values should be passed as GET parameters:

  • client_id = Issued when you created your app (Application ID). (required)
  • response_type = code - Indicates that your server expects to receive an authorization code. (required)
  • redirect_uri = Indicates the URI to return the user to after authorization is complete. (optional)
  • scope = GLOBAL - It allows you to access client information based on your API licenses. (required)
  • state = A random string generated by your application, which you'll verify later. This parameter’s value should be an anti-forgery token to protect against cross-site request forgery (CSRF). (optional)
Step 2 - Allow Access

After successful login user sees the authorization prompt

If the user clicks "Allow", the service redirects the user back to redirect_uri site with an auth code. Sikka API server generate random AUTH_CODE.

https://redirect_uri?code=AUTH_CODE_HERE&state=123456

  • code = The server returns the authorization code in the query string.
  • state = The server returns the same state value that client passed.

What developer/ API user should do ?

Developer should first compare this state value to ensure it matches the one you started with. You can typically store the state value in a cookie or session, and compare it when the user comes back. This ensures your redirection endpoint isn't able to be tricked into attempting to exchange arbitrary authorization codes.

Storing tokens and credentials

Store your application's credentials and user tokens with care.

Redirect URIs

The redirect_uri parameter is optional. If left out, it will redirect users to the callback URL configured in your app's settings. If provided, the redirect URL's host and port must exactly match the callback URL. The redirect URL's path must reference a subdirectory of the callback URL.

CALLBACK: http://example.com/path

GOOD: https://example.com/path

GOOD: http://example.com/path/subdir/other

Step 3 - Token( request_key ) Issuing

If the user authorizes your app, Sikka will redirect back to your specified redirect_uri with a temporary code in a code GET parameter, as well as a state parameter if you provided one in the previous step. If the states don't match, the request may have been created by a third party and you should abort the process.

Your server exchanges the auth code for an access token:

Sample request :

POST https://api.sikkasoft.com/v2/token
Content-Type : application/json
{
"grant_type":"authorization_code",
"code":"AUTH_CODE_HERE",
"redirect_uri":"REDIRECT_URI",
"client_id":"APPLICATION ID",
"client_secret":"APPLICATION SECRET KEY"
}
  • grant_type = authorization_code - The grant type for this flow is authorization_code.
  • code = AUTH_CODE_HERE - This is the code you received in the query string.
  • redirect_uri = REDIRECT_URI - Must be identical to the redirect URI provided in the original link.
  • client_id = CLIENT_ID - The Application ID you received when you first created the application.
  • client_secret = Application secret key - Since this request is made from server-side code, the secret is included. The server replies with an access token and expiration time [Please note here: 'access_token' and 'request_key' are same.]

Response :

{ 
"scope": "https://api.sikkasoft.com/v2/",
"access_token": "d25c47ca453a42bc9133d76b1719eb18",
"request_key": "d25c47ca453a42bc9133d76b1719eb18",
"token_type": "Bearer",
"expires_in": "86400"
"refresh_token":"01234567-89ab-cdef-0123-456789abcdef"
}

Token refresh

Access tokens/request_keys expire 24 hours after they are issued. The refresh token can be used to make a request for a new access token/request_key, similar to the initial access token exchange. Refresh tokens don’t expire until you delete refresh token.

Sample Request :

POST https://api.sikkasoft.com/v2/token
Content-Type =Application/json
{
"grant_type":"refresh_token",
"refresh_token":"01234567-89ab-cdef-0123-456789abcdef",
"client_id":"application id",
"client_secret":"Application Secret Key"
}

Response :

{ 
"scope": "https://api.sikkasoft.com/v2/",
"access_token": "d25c47ca453a42bc9133d76b1719eb18",
"request_key": "d25c47ca453a42bc9133d76b1719eb18",
"token_type": "Bearer",
"expires_in": "86400"
"refresh_token":"01234567-89ab-cdef-0123-456789abcdef"
}

Revoking tokens

If you want to dispose of an oAuth token, use delete refresh_token.

By revoking the last token associated between your application and a user, your application will not be able to access practice data.

DELETE https://api.sikkasoft.com/v2/refresh_token/{refresh_token}?client_id={client_id}&client_secret={client_secret}

  • refresh_token = oAuth refresh_token you want to revoke. (required)
  • client_id = Application id - Issued when you created your app (Application ID). (required)
  • client_secret = Application secret key - Since this request is made from server-side code, the secret is included.

Step 4 : Install SPC

Download and Install SPC (Sikka Platform Cloud)

Prerequisite

SPC should be install on practice management system server. In short SPC and practice management system should be on same machine SPC will require username and password for sikka account

Step 5 : Fetching and displaying data

To fetch the data via Sikka API you will need request key. Sample API request to generate request key

Request

https://api.sikkasoft.com/v2/start?app_id={appid}&app_key={appkey}&office_id={officeid}&secret_key={secret_key}

Response

{
"scope": " https://api.sikkasoft.com/v2/ "
"request_key":"xxxxxxxxxxxxxxxxxxxxxxxxxxx"
"token_type":"xxxxxx",
"expires_in":"24 hours"
}

For more information about a particular endpoint, go to API v2.0 documentation. You will be taken to the API’s documentation page, which includes what query parameters the API will accept, what the JSON or XML parameters will be in the response, and an example.

Quickstart

In this guide we will walk you through all necessary steps to start accessing data from practice.

1.Authorized practices:

This API will give you the list of practices from which you can access data

https://api.sikkasoft.com/auth/v2/authorized_practices?app_id={your application id}&app_key={ your application key }
  • Returns 'office_id' and 'secret_key'

2.Start call to get Request Key for practices:

In response of ‘authorized_practices’ API you have ‘office_id’ and ‘secret_key’. Use it in ‘start’ API

https://api.sikkasoft.com/v2/start?app_id={your application id}&app_key={ your application key }&office_id={office_id}&secret_key={secret_key}
  • Returns Request Key: i.e '52457c9dhgfttfk88798793a4c7e4fa54902'

3.Patients API call:

API to get the list of patients

https://api.sikkasoft.com/v2/patients?request_key={request_key}

For veterinary hospitals use ‘veterinary_patients’ API to get the list of pets

https://api.sikkasoft.com/v2/patients/veterinary_patients?request_key={request_key}

After step 3

4.Pet Owners call:

API to get the list of pet owners

https://api.sikkasoft.com/v2/guarantors?request_key={request_key}&offset=0&limit=10

For more information about a particular endpoint, go to API v2.0 documentation. You will be taken to the API’s documentation page, which includes what query parameters the API will accept, what the JSON or XML parameters will be in the response, and an example.

API Field Filtering

The default endpoints of the Sikka REST API are designed to be sensible defaults in terms of what data is returned. Fields parameter provides a single way for modifying all responses for an object. For example, in patients API there are around 50 fields but your application needs only 5 of them, Fields parameter allows you to get only 5 fields.

Important Note about Field Filtering

The API exposes many fields on API responses, including things you might not need, or might not fit into how your application works. While it's tempting to modify or remove fields from responses, this will cause problems with API clients that expect standard responses. This includes things like mobile clients or third party tools. You may only need a small amount of data, but it's important to keep in mind that the API is about exposing an interface to all clients, not just the feature you're working on.

What fields Parameter Does

In every Sikka API fields parameter allows to return only requested fields. Other fields will not be display in API response. Please note that there are certain fields which user can not remove from API response. Those are the mandatory fields. To get the whole list of mandatory fields please contact Sikka API team

How to Use Fields Parameter

Sikka API accepts fields as parameters: In fields parameters users needs to specify which fields API should return in response. This means that if you specify

https//api.sikkasoft.com/v2/patients?request_key={ }&fields= firstname,lastname, cell ```
It will return only first name , last name ,cell & mandatory fields only. It will skip / hide other fields.

Examples
```javascript
URL : https://api.sikkasoft.com/v2/practices?request_key={valid request key}

Response :

{
"href": "https://api.sikkasoft.com/v2/practices/1",
"practice_id": "1",
"name": "Second Site Location",
"address_line1": "12345 Any Street",
"address_line2": "",
"city": "Mt. Vernon",
"state": "IL",
"zipcode": "62864",
"phone": "",
"country": "",
"email": "",
"website": "",
"providers": {"href": "https://api.sikkasoft.com/v2/practices/1/providers/"},
"patients": {"href": "https://api.sikkasoft.com/v2/practices/1/patients/"},
"guarantors": {"href": "https://api.sikkasoft.com/v2/practices/1/guarantors/"},
"appointments": {"href": "https://api.sikkasoft.com/v2/practices/1/appointments/"},
"transactions": {"href": "https://api.sikkasoft.com/v2/practices/1/transactions/"}
}

Now if user wants to see only “name” in response and skip other fields

URL : https://api.sikkasoft.com/v2/practices?request_key={valid request key}&fields=name

Response :

{
"href": "https://api.sikkasoft.com/v2/practices/1",
"practice_id": "1",
"name": "Second Site Location",
"providers": {"href": "https://api.sikkasoft.com/v2/practices/1/providers/"},
"patients": {"href": "https://api.sikkasoft.com/v2/practices/1/patients/"},
"guarantors": {"href": "https://api.sikkasoft.com/v2/practices/1/guarantors/"},
"appointments": {"href": "https://api.sikkasoft.com/v2/practices/1/appointments/"},
"transactions": {"href": "https://api.sikkasoft.com/v2/practices/1/transactions/"}
}

Expanding Objects

Many objects contain the ID of a related object in their response properties. For example, a patient may have an associated practice id, guarantor id, provider d. Those objects can be expanded in line with the expand request parameter. Objects that can be expanded are noted in this documentation. This parameter is available on all API requests, and applies to the response of that request only. You can nest expand requests with the expand parameter. For example, requesting "expand=practice" on a patient will expand the patient object with practice object. Response will be patient API response, including practice object. You can expand multiple objects at once by identifying multiple items in the expand parameter, separated by comma (",").

Request :

URL : https://api.sikkasoft.com/v2/patients/76?request_key={valid request key}&expand=practice

Response :


{
"href": "https://api.sikkasoft.com/v2/practices/1/patients/76",
"patient_id": "76",
"guarantor_id": "76",
"firstname": "Kvana",
"middlename": "",
"lastname": "Aws4",
.....
"practice_id": "1",
        "practice": {
        "href": "https://api.sikkasoft.com/v2/practices/1",
        "practice_id": "1",
        "name": "Test Dental",
        "address_line1": "",
        "address_line2": "",
        "city": "San Jose",
        "state": "CA",
        "zipcode": "95110",
        "phone": "xxx-xxx-xxxx",
        "country": "",
        "email": "",
        "website": "",
        "description": "",
        "providers": {
        "href": "https://api.sikkasoft.com/v2/practices/1/providers/"
        },
"hygienist": ""
}

Pagination

Requests for collections can return between 0 and 4999 results, controlled using the limit and offset query parameters. All end points are limited to 500 results by default.

GET /v2/patients?request_key={request_key}&offset=0&limit=4999 Return rows from 0 to 4999

The offset should be the page offset (not the item offset). Also, limit will denote page size, along with limit of rows returned.

 offset = 0 and limit = 940 will return the 1st 940 rows
offset = 1 and limit = 940 will return rows 941 to 1880
offset = 1 and limit = 941 will return rows 942 to 1882 (Page offset = 1, page size = 941, limit rows = 941)
offset = 2 and limit = 940 will return rows 1881 to 2820

Modified Records

How to get only modified records ?

There are two ways to get modified records

  1. Use practice_events API. It will return data with specific records with flag ( added , deleted or updated)

  2. Pass loaded_startdate and loaded_enddate to API . It will return change logs of records with flag ( added/deleted) . see below example

There are below parameters in Sikka API to get only modified records :

Parameter Description Required
loaded_startdate Start date for getting only changed record set. Date format : yyyy-mm-dd or yyyy-MM-ddTHH:mm:ss No
loaded_enddate End date for getting only changed record set. Date format : yyyy-mm-dd or yyyy-MM-ddTHH:mm:ss No
flag Flag for data changes (added, deleted) No
interval Value must be integer.
'interval' parameter allows user to fetch records , which has been changed in last minutes.
This will be helpful when user does not know loaded_startdate/loaded_enddate and just want to fetch records which has been changed in last minutes (let say 5,10,15.. etc minutes). Maximun value for interval is 1440. You can fetch data which has been changed in last 24 hours (1440 minutes, interval=1440) without specifying loaded_startdate and loaded_enddate.
Note : Make sure Sikka platform utility is up and running on client machine. To check when Sikka platform utility (SPU) has refreshed, call 'authorized_practices' and get 'data_insert_date'.
No

loaded_startdate & loaded_enddate will help you to fetch modified records between given date time range. flag indicates whether record has been deleted or added.

https://api.sikkasoft.com/v2/{api_name}?request_key={}&loaded_startdate={ }&loaded_enddate={ } 

Response :

{
"href": "https://api.sikkasoft.com/v2/practices/1/appointments/3206e13d",
"appointment_sr_no": "3206e13d",
"patient_id": "1",
"operatory": "",
"date": "2015-11-02",
"time": "08:40:00",
"length": "60",
"description": "testing1",
"amount": "9999.0000",
"status": "confirmed",
"last_changed_date": "2015-12-21",
"appointment_made_date": "2015-11-02",
"provider_id": "LW",
"flag":"Deleted/ Added", [it will tell you record is deleted or added]
"patient_name":"Sat Yen",
"guarantor_id": "1",
"guarantor_name": "guarnator1"
} 

Example :

1.Sikka API (like patients, appointments etc... ) always shows live data; extracted from PMS. Whenever you call Sikka API it is latest data.

How to check latest data activity & retrieve modified records :

1a. To check when Sikka has pulled data from PMS, you can use 'authorized_practices' API, instead keep calling Sikka APIs (patients, appointments, transactions etc... ).

'authorized_practices' API will give you the status of each practice with refresh date & when last time data inserted.

https://api.sikkasoft.com/auth/v2/authorized_practices?app_id={your application id }&app_key={your application key} 

Response :

{
"office_id": "_D....",
"domain": "Dental",
"href": "https://api.sikkasoft.com/auth/v2/authorized_practices/D15",
"secret_key": "_xxxx_.....",
"practice_name": "",
"address": "1650 B_f",
"city": "Gettysburg",
"state": "PA",
"zip": "17325",
"practice_management_system": "SoftDent",
"financial_system": "",
"practice_management_system_refresh_date": "2017-03-01 14:04:08"
"data_synchronization_date": "2017-03-01 14:09:04",
"data_insert_date": "2017-03-01 14:10:08", [You need to check this time and it should be your trigger time to call APIs. If this time is greater than your last API call time then you can run APIs again to pull data.]
"practice_management_system_version": "V14.2",
"practice_management_system_refresh_date_time_zone": "Eastern Standard Time" [It shows above date time is in which time zone.]
}

1b. For example :

Current time is 2017-03-01 11:52:00 & last data_insert_time at 2017-03-01 10:52:00. Now you want to get the list of how many appointments inserted and deleted from PMS.

https://api.sikkasoft.com/v2/appointments?request_key={}&loaded_startdate=2017-03-01T10:52:00&loaded_enddate=2017-03-01T11:52:00

Response :

{
"href": "https://api.sikkasoft.com/v2/practices/1/appointments/3206e13d",
"appointment_sr_no": "3206e13d",
"patient_id": "1",
"patient": {
    "href": "https://api.sikkasoft.com/v2/practices/1/patients/1"
    },
"operatory": "",
"flag":"Deleted/ Added", [it will tell you record is deleted or added],
"patient_name":"Sat Yen",
"guarantor_id": "1",
"guarantor_name": "guarnator1"
}

Output Formats

The Sikka API handles multiple output formats. Currently, the only supported formats are JSON and XML Output formats are selected with a specifier that is appended to the URL, like :

JSON response :

https://api.sikkasoft.com/v2/{api name}/json?request_key={ }

XML response :

https://api.sikkasoft.com/v2/{api name}/xml?request_key={ }

Default response :

https://api.sikkasoft.com/v2/{api name}?request_key={ }

JSON is the default, and will be used if nothing is specified.

HTTP Compression

Sikka API supports HTTP compression of response bodies using standards defined by the HTTP 1.1 specification. Enabling compression is recommended because it reduces bandwidth usage, and time spent retrieving data.

To enable compression, include the following HTTP header in the request:

GET        /patients         HTTP/1.1
Host:     www.domain.com
Accept-Encoding:     gzip,compress

The server understands the compression algorithms from Accept-Encoding and use algorithm to compress the representation before serving it. When successfully compressed, server lets know the client of encoding scheme by another HTTP header i.e. Content-Encoding

200 OK
Content-Encoding:     gzip

Compression can save a lot of bandwidth, with very little cost in additional complexity. Also you may know that most web browsers automatically request compressed representations from website host servers – using above headers.

References:

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3

Error Codes

Error Code HTTP Code HTTP Code Description Short Message Long Message More Info
API0003 200 OK OK Request Session terminated successfully.
API0004 200 OK Email/Text message sent successfully.
API0005 200 OK Email/Text message not sent.
API0006 200 OK Call details logged successfully.
API0008 200 OK Appointment status not logged.
API1001 400 BadRequest Missing Parameter ApplicationID is missing. Please provide the applicationid.
API1002 400 BadRequest Missing Parameter ApplicationKey is missing. Please provide the applicationkey.
API1003 400 BadRequest Missing Parameter MID is missing. Please provide the mid.
API1004 400 BadRequest Missing Parameter Requestkey is missing. Please provide the requestkey.
API1005 400 BadRequest Missing Parameter SecretKey is missing. Please provide the secretkey.
API1006 415 UnsupportedMediaType Sikka API supports json/xml Sikka API does not support response format. Please request with json/xml.
API1007 200 OK Appointment status logged successfully
API1020 400 BadRequest Missing Parameter One of the parameter is missing. Please provide all the parameters in syntax of service.
API1025 400 BadRequest Request key expired Request key is not valid, it is expired. Please generate new request key and make new request.
API1026 400 BadRequest Missing/Invalid Parameter One of the parameter is missing or invalid.
API1027 400 BadRequest
API2001 500 InternalServerError Internal Error Internal Error. Please contact Sikka API Support.
API2002 503 ServiceUnavailable Try again later. The Sikka APIs are up, but overloaded with requests. Try again later.
API2003 401 Unauthorized Authentication/Authorization Failed ID or key is incorrect. This error can be caused by an incorrect application id , application key. In case of provider_accounts & patient_accounts this error can be caused by incorrect username or password.
API2004 401 Unauthorized Authentication/Authorization Failed You are not authorized to use this API. This error can be caused when you try to access API not accessible by you, if you want to use this API contact SIKKA API SUPPORT.
API2005 204 NoContent No content found for given parameter Request is processed successfully, but no data/content returned.
API2006 500 InternalServerError Error occured while processing request The server encountered an error while processing your request and failed. Please contact Sikka API Support.
API2007 401 Unauthorized Authentication/Authorization Failed You are not authorized to access practice details with Sikka API. This error can be caused when you try to access practice details not accessible by you. If you want to access this practice's details with Sikka API contact practice and ask to allow access.
API2009 404 NotFound Resource not found The resource you requested does not exist. The resource you requested does not exist.
API4001 200 OK
API4002 200 OK Error while decrypting string Error occured due to invalid character in encrypted string or invalid passkey or bytekey. Please check passkey/bytekey, encode encrypted string with URL Encoding to replace invalid characters.
API4003 200 OK Error while decrypting password Error occured due to invalid character in encrypted password or length, invalid passkey or bytekey. Please check passkey/bytekey, encode encrypted password with URL Encoding to replace invalid characters.
API4004 200 OK Error while decrypting email or username Error occured due to invalid character in encrypted email/username or length, invalid passkey or bytekey. Please check passkey/bytekey, encode encrypted email/username with URL Encoding to replace invalid characters.
API4005 200 OK Error while decrypting verification code Error occured due to invalid character in encrypted verification code or length, invalid passkey or bytekey. Please check passkey/bytekey, encode encrypted verification code with URL Encoding to replace invalid characters.
API4001 200 OK
API4007 200 OK
API2010 500 InternalServerError Data not uploaded for this customer The data has not yet been uploaded for this customer. If it has been more than 4 hours since the installation, please contact Sikka Support for assistance. Please contact Sikka Support.
API2011 429 Too Many Requests Data limit exceeded Data size per practice per day exceeded Please make request to the datalimit API for more information.
API2012 429 Too Many Requests Request limit exceeded Requests per practice per day exceeded Please make request to the datalimit API for more information.
API2013 409 Conflict Resource already exists You attempted to do something which would leave a resource in an inconsistent state, such as create a resource with an already taken name or id. Please check name or id and resubmit the request again.
API2015 409 Conflict Resource already exists You attempted to do something which would leave a resource in an inconsistent state, such as create a resource with an already taken un or cell. Please check un or cell and resubmit the request again.
API2016 201 Created New resource created successfully
API2018 410 Gone
API2019 422 Unprocessable The request was unable to be processed due to it containing invalid parameters.
API2014 405 Method Not Allowed Method not allowed for the resource Requested method not allowed for the resource Please contact Sikka API support
API2017 412 Precondition Failed The server does not meet one of the preconditions that the requester put on the request. -- --

Webhooks

Webhooks allow you to set up your Apps which subscribe to certain events on practice data or Sikka Platform Cloud. When one of those events is triggered, we'll send a HTTP POST payload to the webhook's configured URL. Webhooks can be used to update your production server or CI builds and let you know about latest activity. Once webhook configured , the webhook will be triggered each time one or more subscribed events occurs. You can create up to 2 webhooks for each event on each target

Webhooks require a few configuration options before you use of them.

Payload URL

This is your server endpoint that will receive the webhook payload. For example , you want to received events on
https://<yourwebsitename>/api/receieve_payload Or https://<yourwebsitename>/api/payload

Content Type

At current Sikka Webhooks can be delivered using json format: The application/json content type will deliver the JSON payload directly as the body of the POST.

Events

When configuring a webhook, you can choose which events you would like to receive payloads for. Only subscribing to the specific events you plan on handling is useful for limiting the number of HTTP requests to your server. You can change the list of subscribed events through the UI anytime. Each event corresponds to a certain set of actions that can happen to practice data or Sikka Platform Cloud. For example, if you subscribe to the Data Refresh event you'll receive detailed payloads every time when Sikka Practice Utility data refresh completed To create webhook , log in to Sikka API portal. Click on webhook. Enter required information and click on Add Webhook, it's time to check on your server to test the if events are receiving or not.

The available events are :

Name Description
Data_Refresh This indicates local SPC refresh is completed and data be available via API
patient When practice chang patient records , new patient added or deleted , this event will trigger.
transaction Coming Soon
appointments Coming Soon
==Note : Sikka Practice Utility has to be up and running on server for all events==
## Payloads
Each event type has a specific payload format with the relevant event information.
In addition to the fields documented for each event, webhook payloads include the office_id , practice_id on which the event occurred on
### Headers
HTTP POST payloads that are delivered to your webhook's configured URL endpoint will contain several headers:
Example delivery
```
POST /payload HTTP/1.1
Host:
X-API-callback-key: xxxxxxxxx
Content-Type: application/json
Content-Length: 6615
{
BODY
}
```
### Webhook payload example
#### Data_refresh :
```
{
"event": "Data_Refresh",
"office_id": "D24710",
"practice_id": 1,
"data_synchronization_date": "2018-04-04 17:03:07",
"practice_management_system_refresh_date": "2018-04-04 17:01:21",
"financial_system_refresh_date": "1111-11-11",
"web_upload_date": "2018-04-04 17:03:07",
"data_insert_date": "2018-04-04 17:11:34",
"practice_management_system_refresh_date_time_zone": "Eastern Standard Time",
"practice_management_system": "Dentrix",
"practice_management_system_version": "V16.6",
"financial_system": "",
"financial_system_version": "",
"utc_difference_in_minutes": "240",
"spc_schedule_time": "5:00 PM",
"spc_schedule_type": "Daily"
}
```
#### Patient :
{
    "event": "patient",
    "office_id": "D20226",
    "practice_id": "1",
    "generated_time": "2018-04-04 17:06:00"
}

List of APIs

PUBLISHER

Sikka
Sikka API seamlessly connects to over 96% of retail healthcare like dental, veterinary, hearing, and vision offices, and is processing billions of transactions every day.

CATEGORIES

Imports

50+