API & the public website

The public hospital website and the BridgeERP REST API are two sides of one system: a marketing-and-services website that patients see, fed entirely by JSON endpoints that read from the clinical back office. Editors curate doctors, departments, services, conditions, news and patient stories inside BridgeERP HMS; the website renders them live; and online bookings and portal actions flow straight back into the clinical records. This page explains how content is authored, the REST endpoints that serve it, the booking flow and the patient portal.

Where to find it

Website content is authored under HMS Core → Configuration → Website Content, and the supporting bridges sit under HMS Core → Integration → HMS Integrations:

Every content record carries a website_published flag and a slug; only published records are served, and the slug is the URL key.

How data flows: back office to website

The website itself is a separate front-end that never touches the database directly. Instead it calls the REST API, a set of public JSON routes rooted at /storefront/api. Each route reads published content (or, for portal routes, a token-authenticated patient’s own data) and returns JSON. The flow is: editor publishes a record → the website requests the matching endpoint → the API serializes the published record → the page renders. Writes go the other way: a booking or a comment posts to the API, which creates a real clinical or content record.

Content endpoints (GET)

Action endpoints (POST)

Step-by-step: how an online booking lands

1. The visitor picks a doctor or department, a date and a time, and submits the booking form.
2. The site POSTs to /storefront/api/appointment/book with name, phone, optional email, gender, the doctor / department slug, date, time and channel (in-person or telehealth).
3. The API looks up the patient by phone; if none exists it creates one.
4. It resolves the doctor profile slug to the clinical staff member and the department slug to the clinical department, then creates an hms.appointment stamped with the facility, the local time converted to UTC, and the online_booking flag.
5. The appointment opens in a pending state, ready for reception to confirm. A honeypot field silently absorbs bot submissions.

The patient portal

Returning patients sign in to a self-service portal whose routes sit under /storefront/api/portal. Login takes a phone number plus date of birth, matches an existing patient record, and issues a token; subsequent calls send that token. Portal routes include:

Booking payload reference

Roles & publishing

Website editors curate content from the back office; the public API routes themselves require no login because they only serve published records and token-scoped portal data. Partner access to the stakeholder portal is governed by Configuration → Stakeholder Portal → Partner Access, with all access written to the Audit Log.

Tips & troubleshooting

Related

• Integration overview
• Reception — register a patient
• FHIR Interoperability