Guide
  • SDK

    • PHP
    • .NET
  • Postman

    • Postman Collection
Api Docs
Guide
  • SDK

    • PHP
    • .NET
  • Postman

    • Postman Collection
Api Docs
  • Getting Started

    • Getting Started
    • Integration process
  • Tools and libraries

    • SDK for PHP
    • SDK for .NET
    • Postman Collection
  • Fundamentals

    • Authorization
    • Errors
    • Extensions
    • Rate Limits
  • API Objects

    • Resources
    • Managing calendars
    • Online Features
    • Patient Presence
  • Callbacks

    • Push vs Pull
    • Real-time requests
  • Mappings

    • Vendor mapping
  • Changelog

    • Changelog
DOCPLANNER INTEGRATIONS

Vendor mapping

Mapping is a crucial element of integration, determining whether data synchronization is seamless and robust. Read this article for our best practices and recommendations for effective mapping.
Docplanner integrations - img
Docplanner integrations - icon

Discover tips for designing a user-friendly mapping interface.

Docplanner integrations - icon

Learn which objects can change over time and should be monitored during the mapping process.

Docplanner integrations - img

Before starting the mapping process, carefully review our Resources section, which explains all relevant contexts in detail.

The general mapping workflow is illustrated in the following diagram:

Step 1: Retrieve and Store Resources

Begin by retrieving and storing all relevant resources for your API client. The primary entities requiring mapping on the partner side are:

  • Facilities
  • Doctors
  • Addresses (both dictionary and address-specific)
  • Services
  • Insurances

To ensure proper synchronization, each Docplanner entity should be mapped to a corresponding object in the partner system’s database.

Step 2: Manage and Maintain Mappings

We highly recommend providing partners and clients with an interface to manage mappings independently, as configurations may change frequently. Below is an example of a mapping interface:

Step 3: Monitor Resource Changes

Maintaining up-to-date mappings is essential, as certain resources can change within the Docplanner interface. Resources particularly subject to change include:

  • Services
  • Insurances

Services require special attention. For example, deleting a service that is actively used for slot synchronization will cause calendar updates to fail. To ensure accuracy, we advise running a regular synchronization process that fetches the latest services for each mapped resource using the getAddressServices endpoint:

https://www.{domain}/api/v3/integration/facilities/{facility_id}/doctors/{doctor_id}/addresses/{address_id}/services

Sample response:

{
  "_items": [
    {
      "id": 101,
      "name": "USG",
      "is_default": true,
      "is_price_from": false,
      "price": 100,
      "description": "Description of service",
      "service_id": 1
    },
    {
      "id": 103,
      "name": "EEG",
      "is_default": true,
      "is_price_from": false,
      "price": null,
      "description": "Description of service",
      "service_id": 3
    }
  ]
}

Any address services in your local mapping that are no longer returned by this call should be unmapped, as maintaining obsolete mappings can cause issues during calendar updates.

My system doesn't use addresses. What should I do?

If your system does not utilize addresses as a resource, consider mapping the address entity to your own concept of a "schedule," if relevant. Otherwise, you may use a concatenated value combining clinic and doctor/resource identifiers.