# 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](/docs/integrations/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 |
{.table}

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](/docs/integrations/integration-overview#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.

## Related

- [Integration overview](/docs/integrations/integration-overview)
- [Appointment Sync Service](/docs/integrations/appointment-sync-service)
- [Synced appointments](/docs/appointments/synced-appointments)

---
Source: https://diarybook.com/docs/integrations/requirements-and-compatibility/