Many labs already have a website. Usually it is a brochure: an address, a phone number and a rate list that was correct the day it was typed. Patients still have to call to book, and still have to come back or wait for a message to get their report.
A Pulse Solution can sit behind that website. The same account your front desk uses can feed the website its test list, take bookings from it and hand back reports once they are released. This guide explains what the website can do, how a lab switches it on, and the limits you should know before you ask a developer to build it.
It is a Premium feature, and it needs a developer on your side. Both points are covered below.
What your website can do
The connection is called API & webhooks. An API is a set of addresses that another program can call to read or send data. A webhook works the other way: A Pulse Solution calls your website when something happens.
| On your website | How it works |
|---|---|
| Show your test list with prices, sample type and turnaround | The website reads GET /api/v1/tests. It is the same catalogue your desk uses, so a price changed in Settings is the price the website shows. |
| Online booking: register the patient and book their tests | POST /api/v1/patients, then POST /api/v1/orders with the test codes. The order arrives in your account with its invoice and sample tubes, like a booking made at the desk. |
| Let a patient download their report | GET /api/v1/orders/:id returns the results and a report link valid for 30 days, only once the report is released. |
| Tell the website a report is ready, for example to email the patient | A webhook: A Pulse Solution calls your website on order.created and report.released. |
Bookings go through the same checks as the desk
A booking from the website is not a second, looser way into your lab. The API passes it to the same registration and order screens your staff use, so the same rules apply: required fields, the duplicate-patient check on phone number and CNIC, invoice numbering, and sample tubes. Each booking is recorded in the activity log under the admin who created the key.
If a test code is wrong or a test has been switched off, the booking is refused with the reason instead of half-saved.
Results stay private until you release them
The API never shares a result before the report is released (approved). Before that, an order shows its status and its tests, with no values. So the website cannot show a patient a result your pathologist has not signed off.
How a lab switches it on
- Sign in as the lab's admin and open Settings → Tests → API & webhooks.
- Click to create an API key and give it a name, such as "Website". Choose Read if the website only shows tests and reports, or Read + place orders if it will also take bookings.
- Copy the key. It starts with
apk_and is shown only once, so paste it somewhere safe straight away. - Give the key to your website developer. Their code calls your lab's own A Pulse Solution
address, the one your staff sign in at, followed by
/api/v1/..., with the headerAuthorization: Bearer apk_.... - Optional: on the same page, add your website's address as a webhook and tick the events it should hear about, such as Report released.
The settings page lists every endpoint with a working example, so the developer has what they need without a call to us.
Make one key for each system that connects: one for the website, another for a hospital system if you have one. Each key can then be revoked on its own without breaking the others.
Your lab's data stays with your lab
- A key works for one lab only. It is tied to your lab's account and address, so labs never see each other's data, even though they use the same software.
- Only a fingerprint of the key is stored. Even we cannot read your key back to you. If it is lost, create a new one and revoke the old one.
- Revoking is immediate. The moment a key is revoked, anything using it stops working.
- A key stops placing orders if its creator leaves. Bookings run as the admin who created the key. If that staff member is deactivated, the key can no longer place orders, and you create a new one.
- Webhooks are signed. Each message carries an
X-APulse-Signatureheader made with a secret only your website knows, so the website can check the message really came from your account. Webhooks are only sent to publichttps://addresses.
What it does not do, and what your developer must handle
These limits matter, and it is better to know them before the website is built:
- It needs a developer. This is not a plug-in you switch on. Someone has to write the website's side of the connection.
- The calls must come from your website's server, not the visitor's browser. The API key is a password to your lab's data, so it must never appear in a web page. The API does not accept calls made directly from a browser, so a purely static website with no server-side code cannot use it on its own.
- Your website must check who the patient is before it shows a report. The key can read any released order in your lab. Before showing a report, the website has to confirm the person asking is that patient, for example by checking an order number together with the phone number on file. That check is the website's job, not the API's.
- It does not take payment. A booking creates the order and its invoice in your account. Collecting the money, online or at the counter, is separate.
- Each key may make up to 120 calls a minute. That is plenty for a lab's website, but a developer should not ask for the whole test list on every page view. Fetching it once and keeping a copy for a few minutes is the usual approach.
- It is on Premium only. On Basic and Medium the settings page explains that the API is part of Premium, and the API refuses calls.
Do you need this?
If your website is a brochure and your patients book by phone or WhatsApp, you may not. Your reports can already reach patients through the online report link and QR code, on every plan, with no website work at all.
It is worth it when:
- you want patients to book online and walk in with an order already created;
- your website shows a rate list that keeps going out of date;
- you want a "download your report" page on your own domain, under your own name;
- a hospital or clinic you serve wants its own system to read your results. That uses the same API, explained in LIS vs LIMS and on the hospital laboratory software page.
Try it before you commit
The free demo unlocks every module, Premium included. Open a demo lab, create a key under Settings → Tests → API & webhooks, and let your developer call it against a few test patients. If it fits how your website works, ask us for a quote for Premium.