Skip to content

APIS & INTEGRATIONS / RAKT

Plan your
RAKT integrations.

RAKT has API keys, app permissions, and webhooks for connecting other systems. Agree what information will be exchanged, who can access it, and how failures will be handled.

Explore the detail

PLANNING A SYSTEM CONNECTION

Decide what information
the systems exchange.

  1. 01
    The record

    Agree identifiers, fields, and source of truth.

  2. 02
    The permission

    Define read or write access and relevant scopes.

  3. 03
    The exchange

    Specify the request, event, and expected response.

  4. 04
    The exception

    Test repeats, failures, and reconciliation.

Start with the exchange you need

Name the other system and the information it needs to send or receive. Decide which event should start the exchange. Sending an order and receiving a reviewed result are separate requirements, even when they involve the same systems.

Bring a sample message or interface specification if you have one. Agree which system holds the authoritative patient identifiers, catalogue codes, statuses, and financial values. Decide what should happen when the two systems disagree rather than assuming their fields have identical meanings.

Read access and write access are different

RAKT organisation API keys distinguish read-only and writable access. Installed applications can also have granted scopes, and disabled applications are rejected by the relevant permission checks. Set these permissions for the work the connection needs to do.

Review the required endpoints and permissions for the specific integration. Use the least access that supports the agreed workflow. An integration that only reads operational information should not receive broader write authority merely to make initial setup easier.

Events need a delivery plan

RAKT can send event notifications, called webhooks, to another system. The messages include a signature that the receiver can check to verify their source. It does not, by itself, prove that the receiving system accepted or correctly processed the event.

Define the events in scope, how the receiver checks authenticity, and what a repeated or delayed notification means. Agree who investigates delivery failures and how a missed exchange is reconciled. Test those cases with non-production data before the integration becomes part of daily work.

Confirm the exact connection you need

The API supports integration work. Connections to a particular analyser, accounting package, insurer, or government service need to be confirmed individually. Vendor-specific interfaces can have their own credentials, certification, network, and deployment requirements.

Ask for a demonstration of the exact connection you need or a written implementation scope. Record which party owns each part, including changes on the other system. Review any third-party fees or usage limits with that provider rather than treating them as included by default.

Test failures as well as successful requests

A useful integration test includes an unknown identifier, a repeated request, an expired credential, a disabled application, and a period when the destination cannot be reached. It should also include a normal record that the team can trace from one end to the other.

For each test, save the expected request, response, resulting record, and steps to recover from a failure. Both teams can use these examples when testing the connection or investigating a problem after launch.

COMMON QUESTIONS

Questions about this topic.

Is every third-party connector included?

Confirm each connection separately, including the product, interface, required setup, and any additional work.

Can an organisation API key be read-only?

Yes. The API permission layer distinguishes read-only and writable keys; installed-app scope checks also apply where configured.

Do webhooks guarantee that a destination processed an event?

No. Delivery and processing must be checked with the receiving system. Define monitoring, retries, and reconciliation as part of the integration plan.

PLAN A DEMONSTRATION

See how RAKT handles
your team’s work.

Use fictional examples or blank formats. Keep patient information out of an initial enquiry.

Arrange a walkthrough