How SuggiCare Fits Into Your Organisation

A plain language integration guide for centre owners, IT teams and executives.

Document type, Knowledge Sheet Audience, Centre Owners, IT, Procurement, Executives Version 1.0

The short answer

Most organisations start on SuggiCare as a hosted service (SaaS), with no IT work needed beyond creating accounts. Larger or enterprise organisations layer on integrations later, on their own schedule. You do not have to choose between SaaS and integrated, you grow into integration.

Rule of thumb. If you have under 10 sites or no dedicated IT team, run SuggiCare as SaaS. If you have an existing rostering, EHR, payroll or finance platform you want SuggiCare to talk to, add API integration in Phase 2.

Three ways organisations adopt SuggiCare

Option A, SaaS only

Use SuggiCare in the browser, no IT changes

Your team signs in at suggicare.io. Staff use the web app and the kiosk tablet. Families use the family app. Devices pair through the facility bridge tablet. Nothing is installed on your network.

Setup time, same day.
IT effort, none.
Best for, single site, small group, or first 90 days of any rollout.
Data, hosted in AWS Sydney with full data residency.

Option B, SaaS plus light integrations

SaaS, with bridges to a few existing tools

You stay on the hosted SuggiCare platform, but we connect a few of your existing systems through ready built bridges. No code from your side.

Single Sign On, Microsoft 365, Google Workspace, Okta, Azure AD.
Calendar sync for rostering, Outlook and Google Calendar.
CSV imports for staff and resident lists.
Webhooks out, alerts and incidents posted to your existing channels (Teams, Slack, email).
Setup time, 1 to 3 weeks. IT effort, light, an admin enables SSO and approves connections.

Option C, Full enterprise integration

API, SFTP and webhook integration into your stack

For enterprise groups (multi state aged care, hospital networks, large NDIS providers, national childcare chains). SuggiCare exposes a documented REST API, secure webhooks and SFTP for batch files. Your platforms read and write into SuggiCare directly.

Two way sync with rostering platforms (Humanity, Deputy, Tanda, internal HRIS).
Read only feeds into your data warehouse or BI tool (Power BI, Tableau, Snowflake, Looker).
Webhook push of incidents and alerts into your case management or EHR.
SCIM provisioning so leavers and joiners flow automatically from your HRIS.
Setup time, 4 to 12 weeks. IT effort, scoped project with the SuggiCare integration team.

What we connect to, by category

Category	Examples	Method
Identity and SSO	Microsoft 365, Google Workspace, Okta, Azure AD, OneLogin	SAML 2.0, OAuth 2.0, OpenID Connect
HRIS and payroll	Employment Hero, Xero, Workday, BambooHR, MYOB, KeyPay	API or SFTP nightly
Rostering	Humanity, Deputy, Tanda, Microkeeper, internal systems	API or webhook
EHR and client systems	Carelink, Lumary, Procura, AlayaCare, internal EHR	API, webhook out, HL7 FHIR on request
Finance	Xero, QuickBooks, NetSuite, MYOB, Sage	API push of invoices and CSV exports
Communications	Microsoft Teams, Slack, SMS gateways, email	Webhook out
BI and warehousing	Power BI, Tableau, Looker, Snowflake, BigQuery	Read only API or scheduled CSV to S3
Compliance feeds	ACQSC reporting, NDIS portals, ESG reporting	Generated exports, API on request

What "API integration" actually looks like for your IT team

For organisations on Option B or C, here is what SuggiCare provides on day one of an integration project.

A scoped, time bounded API key per environment (sandbox, production).
OpenAPI 3.1 documentation, with example payloads and Postman collection.
Webhook signatures so your endpoints can verify it is really us.
Rate limits, error contracts and a status page.
A named SuggiCare integration engineer for the duration of the project.

Example, push of an alert acknowledgement from your case management tool back into SuggiCare:

POST https://api.suggicare.io/v1/alerts/{alert_id}/acknowledge
Authorization: Bearer ORG_API_KEY
Content-Type: application/json

{
  "acknowledged_by": "staff_42",
  "method": "case_management",
  "note": "Visited resident, settled, no action required"
}

Example, webhook out when SuggiCare detects an incident:

POST https://your-system.example.com/suggicare/incidents
X-Suggicare-Signature: t=1715379600,v1=...

{
  "type": "incident.opened",
  "organisation_id": "org_123",
  "site_id": "site_45",
  "ward_id": "ward_a",
  "recipient_id": "rec_999",
  "severity": "high",
  "summary": "Sustained heart rate drift outside personal baseline",
  "occurred_at": "2026-05-10T07:53:00+10:00"
}

Devices and the on site bridge

SuggiCare wearables pair through the facility bridge tablet using each recipient's QR code. Wearables never pair to a resident's personal phone. The bridge is a standard Android or iPad tablet supplied by the facility or by SuggiCare. It only needs Wi-Fi and a power point.

No new firewall rules in most cases. Outbound HTTPS to *.suggicare.io is enough.
Bridge tablet runs in kiosk mode, locked to the SuggiCare app.
One bridge supports up to 60 wearers in a typical residential aged care wing.

Decision guide for the demo

If your organisation looks like this	Recommended path
1 to 3 sites, no dedicated IT, want to start in days	Option A, SaaS only
Multi site, has Microsoft 365 or Google Workspace, wants SSO and Teams alerts	Option B, SaaS plus light integrations
National or multi state, existing rostering, HRIS or EHR, BI team, procurement process	Option C, Full enterprise integration
In-home care provider with a coordinator app and a CRM	Option B to start, Option C inside 6 months
NDIS provider with plan management and case management tools	Option C, with webhook out into case management

Security, data residency and compliance

Data is hosted in AWS Sydney. Data residency is a hard constraint, not a setting.
Row Level Security ensures each organisation only ever sees its own data.
SOC 2 aligned controls, audit logs on every privileged action, encrypted in transit and at rest.
SSO and SCIM remove the risk of orphan accounts when staff leave.
Care Alerts is not a medical device, no medical advice or emergency dispatch.

What we ask the organisation to provide

For Option A, a list of staff emails and the resident or child roster.
For Option B, an admin in your identity provider to authorise SSO, and the names of the tools you want bridged.
For Option C, a technical contact, the systems in scope, and a sandbox of those systems for the integration team to test against.

Typical timeline

Week	Option A	Option B	Option C
1	Live in production	Live in production	Discovery, scope sign off
2 to 3	Optimisation, training	SSO, calendar, webhooks live	Sandbox API connected
4 to 8	BAU	BAU	HRIS, rostering, EHR connected, UAT
9 to 12	BAU	BAU	Production cutover, hypercare