Requirements and compatibility
The requirements for integrating with Diarybook are deliberately small. Your system produces a delimited text file and uploads it; Diarybook does the rest. This page covers what that needs from your side.
Source systems
Diarybook takes appointment feeds from IPMS and NIMIS in production today.
That list is shorter than the compatibility picture, because the feed is a CSV file rather than a system-specific interface. Any system that can run a scheduled query and write a delimited text file can feed Diarybook — there is no adapter to wait for and no vendor certification to obtain. The practical question is whether your system can export on a schedule, not whether Diarybook supports it by name.
The file format is specified in full in the integration overview.
Network access
| Purpose | Destination | Protocol and port | Direction |
|---|---|---|---|
| Appointment feed | xfer.diarybook.com | SFTP, port 22 | Outbound, from whichever host runs your upload |
| Staff portal | portal.diarybook.com | HTTPS | Outbound, from staff workstations |
Nothing inbound to your network is required. Diarybook holds no route into your systems and no credentials against your database.
One thing is needed at Diarybook’s end rather than yours: the source IP address you upload from has to be given to Diarybook in advance so it can be allowlisted. See transferring the file for the SFTP detail and credentials.
Browsers
The Diarybook portal runs in a browser over HTTPS. This is a portal requirement, not an integration requirement — it is the same whether your account is fed by a daily file or used standalone, and integrating changes nothing about it.
Do you need portal access?
The feed itself does not. Once the daily upload runs, appointments sync and reminders send without anyone signing in.
Staff need the portal for what comes back: monitoring client replies and confirmation status, and querying which messages were sent to whom. If that visibility is wanted inside your own system instead, the write-back option below is the alternative.
Sending replies back to your system
Optional, and available on request. Each time a client reply is received, Diarybook posts it to an HTTPS endpoint that you supply and host — an HTTP POST per reply, rather than a batch.
No customer uses this to date. Treat it as built but unproven: the endpoint contract, payload shape and authentication are agreed with your Diarybook account manager during setup rather than taken from a published specification. If replies reaching your source system matter to your business case, raise it early rather than after go-live.