Skip to content
Start in the sandbox
All connectors
One Touch Health logo

One Touch Health

Healthcare systems

Move care records through One Touch Health with the right person checking each step.

7 ways to read.

Try this in the sandboxBring us a workflow

Quality checks

Built and tested with example responses.

  1. Ready to connect: doneEvery listed action is built in.
  2. Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
One Touch Health with Nexra

Connected, approved, proven.

The things teams do most with One Touch Health, an example flow with a person in the loop, and what Nexra keeps as proof.

Top actions

  • List areasareas.listRead

Example flow

  1. One Touch Health · List areasareas.listDone
  2. Nexra · Record the decision and result in the evidence chainProven

Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches One Touch Health.

What gets logged

  • Whether it ran on its own or who approved it, and under which rule
  • A fingerprint of the exact request sent to One Touch Health
  • One Touch Health's reply: what it created or changed
  • One entry in the evidence chain, linked to the one before

Try this in the sandbox

Run the whole flow with test data in your sandbox, then connect your own account when you are ready to go live.

Try this in the sandboxBring us a workflow

For developers

Technical detail

UK and Ireland: read One Touch Health home-care areas, carers, service users (clients) and status, position and transport lookups through the Connect API. Read only.

OneTouch Health API docs
Source actions
7
Data types
7

What you can map

Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.

areas1
  • List areasSource

    Areas (branches or patches) visible to the API user.

carer positions1
  • List carer positionsSource

    Carer position (role) lookup values.

carer statuses1
  • List carer statusesSource

    Carer status lookup values.

carer transport types1
  • List carer transport typesSource

    Carer transport type lookup values.

carers1
  • List carersSource

    Care workers with display name, status, area, location and external reference.

client statuses1
  • List client statusesSource

    Client (service user) status lookup values.

clients1
  • List clients (service users)Source

    Service users with display name, status and external reference.

Access and limits

Authentication
Dedicated One Touch API user (username and password)
Plans and access
One Touch Health customers with the Connect API enabled. One Touch issues API users on request. Reads are limited to the areas visible to the API user. One Touch keeps one live token per API user, so the Nexra connection must use its own dedicated API user.
Test environment
One Touch does not publish a sandbox; ask One Touch for a test API user on a non-production tenant.
Rate limits
One Touch documents about 8 requests per second. Nexra spaces requests to at most 4 per second per API user and retries HTTP 429 and 503 with backoff.
Pagination
Carers and clients use Laravel page numbers (current_page and last_page) with a server-set page size; lookups and areas return one list.
Provider events
One Touch does not document webhooks on the Connect API. Flows run on demand, on a schedule, or when a scheduled check finds new or changed records.

Before you build a flow

  • Read only. Nexra never calls One Touch create, update, delete, leave, schedule, diagnosis, allergy, note, contact, tag, batch or lockdown endpoints.
  • Use a dedicated One Touch API user for this connection. One Touch keeps one live token per user and a new login invalidates the previous token, so sharing the user with another system (or another Nexra connection with different settings) makes them log each other out.
  • Tokens last about 15 to 20 minutes and cannot be refreshed. Nexra logs in on first use, reuses the token for at most 10 minutes, logs in again once after HTTP 401, and serialises logins per API user so it never logs in concurrently. Sessions are shared within one Nexra API instance; separate instances each hold their own session, so run One Touch flows from one instance or expect occasional re-logins.
  • Not available on Connect C2 and not implemented: visits and rotas, timesheets, invoicing (/invoicing returns HTTP 404 on C2), leave reasons and leave records, and carer qualifications. No documented Connect read path exists for them, and Nexra does not probe guessed paths.
  • Carer and client records keep only IDs, display name, status, area, location and external references. Address, date of birth, phone, email, NI or PPS number, photo, tags and other personal or clinical fields are dropped and never mapped.
  • There is no updatedSince filter on the Connect API; carers and clients are full reads.
  • One Touch does not publish an official public API reference. Paths and shapes come from One Touch's own source documentation and a live verification (areas, carers, clients and the four lookups).
  • Only regional hosts of the form api-xx.onetouchhealth.net are accepted, over HTTPS.

Developer reference

  1. Create the OneTouch Health credentials described above with the narrowest permissions your flows need.
  2. In Nexra, open Connect, then Connections, then New connection, choose One Touch Health, enter its settings and credentials, and tick only the write actions you need. Connection guide
  3. Test the connection, then use its actions as flow sources and destinations. Flow guide
OneTouch Health docsAPI referenceOneTouch Health docsAuthentication

Machine-readable detail: GET /api/public/connect/connectors/onetouch-health and the Connections API.