All the following information relates to the D-Tools System Integrator (on-premises or hosted server) API. This API is not for D-Tools Cloud, but just for the D-Tools System Integrator.

Please take a moment to review our overall API capabilities and considerations. This will help you understand how our API works and will answer most of the preliminary questions you may have. This page is updated when new features become available.

The D-Tools SI API is Cloud-based and has been created to bridge the data from the on-premises (or hosted) D-Tools instance to a cloud API Server, where it becomes available for subscription and updates from/to a 3rd party application.

It is important to understand how our API has been designed in relation to our product: As an on-premises application (regardless of whether the server is installed locally or is hosted), SI has no directly accessible API. Instead, we have created a middleware solution running on our cloud, simulating a queue for data. When you POST data to the API, that data is stored on the API until it is applied to D-Tools SI. To consume data from the API, D-Tools SI must first export data to the API. The export of data (i.e., project export) can be done manually or automatically.

Please note that the old Change Order method (before SI2017, and based on revision compare) is deprecated. Please use the Change Order feature in D-Tools SI and the Projects / Change Orders Subscribe service endpoint to retrieve Change Orders data.

Our webhooks offer a comprehensive range of features and functionalities, tailored to meet diverse user requirements and preferences:

Authentication Options: Users have the flexibility to choose from various authentication methods:

API Key Integration: The inclusion of the API key in the webhook post object enhances both security and integration efficiency.

Webhook Post Object Elements:

Enhanced Reliability: The webhook code in SI v22 logs both successful and failed attempts. In case of failure, the system executes three retry attempts at intervals of approximately 5, 15, and 30 minutes. After four total attempts, no further attempts are made.

Logging and Monitoring: The new Log button in the Manage Webhooks section in SI displays logs of successful and unsuccessful attempts for a selected webhook, including fields like Status, Number/Name, Date, Error, Attempts, and Last Attempted time.

Webhooks are incredibly useful for automating reactions to events within a system or application. They function as user-defined HTTP callbacks that are triggered by specific events. When an event occurs, the source site makes an HTTP request to the URL configured for the webhook. This mechanism allows for real-time data transmission, efficient inter-system communication, and immediate response to events.

Real-world Example: Imagine a scenario in a sales management system where every time a new sale is recorded, a webhook is triggered. This webhook could be configured to automatically send an HTTP request to a CRM (Customer Relationship Management) system. The request would contain details of the sale (like sale amount, customer information, and product details) encapsulated in the webhook post object. This real-time update enables the CRM system to immediately log this new sale, update the customer's purchase history, and trigger other processes like inventory adjustment or personalized customer follow-up emails. This automation not only saves time but also ensures that all systems are synchronized with the latest data, improving efficiency and customer experience.

Below is an example of a JSON payload for a webhook that incorporates the features described above. This example assumes a scenario where a new sale has been recorded, and the webhook is triggered to update a CRM system:

This JSON structure contains the following elements, and it is not customizable:

CREATING A WEBHOOK:

EDITING A WEBHOOK:

We call our API (https://api.d-tools.com) on the IP 52.34.10.235.
This server is located in the US, the West Oregon data center of AWS.

The SI Client directly calls the API endpoint on the AWS server (api.d-tools.com), and it does not go through the SI Server when doing Export to integration.

We offer a series of settings related to Automation. Please refer to the Integration Settings for the most updated list of automation options available on your D-Tools SI version:

a. Always, automatically export a project with "any statuses" to the default integration upon project check-in. This option will always export the project to the API upon project check-in, regardless of the project status. This scenario is for companies that are using Project Management Apps, which require that the project be pushed as they are built/changed/approved/lost, etc This will give a sense of real-time visibility on third-party integrations.

b. Always, automatically export a project with "specific status(es)" only, to the default integration upon project check-in. This is similar to the use case noted above, where multiple recurring pushes are set up. The difference is that only specific statuses are selected.

c. Conditionally, automatically export a project with "specific status(es)" to the default integration upon project check-in. The condition is that if the project status changes, export. If it doesn't change, don't export. As an example, this scenario would be for companies using third-party accounting apps, where they would specify a single status to export to their accounting app, and only (automatically) push it once.

Please go to Start > Setup > Control Panel > Manage Integrations > Settings to set up your automation.

The D-Tools System Integrator (SI) API supports both real-time and scheduled data automation, offering flexibility in how data is exchanged between SI and external systems. The API functions as a staging layer between the on-premise SI environment and external consumers, enabling both push and pull operations using either event-based triggers or time-based schedules.

The SI API supports real-time data availability. When data is published to the API from SI, it becomes immediately accessible for consumption. There is no throttling mechanism or rate-limiting in place on the SI API, allowing integrations to retrieve data as soon as it becomes available.

Integrators can implement a webhook-based design pattern to trigger actions based on specific events, removing the need for polling-based middleware. Webhooks are used to notify external systems that new data is available, prompting a GET request only when necessary. This approach reduces overhead and ensures efficient API usage.

Examples of real-time or event-driven automation include:

In addition to real-time automation, the SI API also supports batch-driven processing for data synchronization tasks that do not require immediate execution. This batch approach is typically used for backend automation tasks such as catalog synchronization or bulk project creation. These scheduled jobs are executed by SI services at defined intervals.

Batch workflows include:

PROJECTS:

CATALOG:

The timer intervals mentioned above are hardcoded in the SI Windows service. These are not imposed by the API, but rather by the internal job scheduler that governs automation routines within the SI environment.

The D-Tools System Integrator (SI) API functions as a queue-based interface that facilitates asynchronous data exchange between SI and third-party applications. This queue model applies to all endpoints and is designed to enable consistent two-way integration. There is no direct access to the data in SI.

When a project is sent to the API:

D-Tools SI supports integration of Change Orders as part of the standard project export workflow. Change Orders are processed using the same API endpoints and logic as regular project exports. Users are encouraged to manage change orders directly in SI using the enhanced functionality available in SI 2018 and later. For more details, refer to the Change Orders documentation: ​Change Orders Overview.

CHANGE ORDERS:

Integrations should focus on managing the full lifecycle of a project, allowing for both creation and updates to occur bidirectionally. While adding items from either system is supported and may be useful depending on the use case, it is important to implement a consolidation strategy.

Best Practice: Recommend item mapping or creation only when the project is first created or updated in D-Tools from a third-party integration. This helps avoid data mismatches between systems.

For the initial sync of clients, vendors, and part libraries, it is recommended to perform a manual import/export using CSV files or leverage existing connectors such as QuickBooks or Outlook. Developing an automated sync for the initial setup is not advised due to the variability in how users manage their source data. Once the systems are aligned, subsequent updates should occur through the normal project import/export process via the API.

D-Tools SI does not manage accounting operations or inventory. If those functions are required, users should integrate D-Tools with a third-party system such as QuickBooks using the corresponding integration tools available from D-Tools or their third-party provider.

Access to the API requires an API key tied to the user’s SI license. All API requests must include the correct API key in the header, as outlined in the documentation: ​API Key Usage.

To manage integrations from within SI, see: ​Manage Integrations Window.

When a project is exported from SI to a third-party system, both project metadata and detailed item-level data are included. Exported fields may include:

Refer to the full schema documentation for details:

When handling labor data via the SI API, it is important to understand how different types of labor are represented in API responses. The SI system distinguishes between fixed labor, variable labor, labor by phase or type, and labor associated with equipment.

1. Fixed Labor

2. Variable (Calculated) Labor

3. Phase-Based or Labor Type-Based Labor

4. Equipment-Associated Labor

To build a stable and predictable integration between a third-party system and D-Tools SI, the following workflow pattern is recommended:

The SI API supports aggregation of project items to reduce payload size and optimize performance during data exchange. This functionality is available through the SubscribeProjects endpoint, which retrieves a specific project using a given Project ID published by an SI user.

When calling SubscribeProjects, you can group project items by one or more of the following dimensions:

This grouping capability is designed to consolidate similar project items into a single entry, with a calculated quantity field that reflects the aggregation.

Items will only be grouped together if the values of all the following fields are identical:

If any of these values differ between two items, they will be treated as separate entries during aggregation.

As of D-Tools SI Version 18, two key fields were introduced for project items:

These fields help accurately calculate the quantity of grouped items, especially in cases involving nested components such as packages or solutions.

The TotalQuantity is derived using the following formula:

This calculation ensures that the final quantity accurately reflects all nesting levels of the item structure.

When importing grouped project items from the API into SI, starting with Version 18, the system no longer splits items into individual units. The Quantity field is respected during import and is visible in the SI interface.

To test the SI API and aggregation behavior, we recommend using the Postman application. It is a free API client that supports request creation, environment management, and response validation. You can use the test key in the endpoints documentation to make GET requests.