Put your schedule where your partners already work

It is 9:15 on a Tuesday. A care coordinator at a referral clinic has a patient on the phone who needs physiotherapy this week. She opens a new tab, calls your front desk, waits on hold, and asks the question your team answers forty times a day: “Do you have anything Thursday morning?” Your receptionist puts someone else on hold to check. Two people and two phone lines, all to read a calendar that already exists.

Calendar embeds remove that call. The coordinator's CRM shows your schedule directly, live, next to the patient record she already has open. It is read-only, it is signed, and it shows exactly as much as you decide.

Every way of sharing a calendar has a catch

Practices that work with partners (referral networks, call centers, a group's head office, their own sales team) have always had to pick one of three imperfect options.

Give them a login. Now a person outside your practice holds an account in your scheduling system. It costs a seat, it usually shows far more than they need, and somebody has to remember to remove it when the partnership ends.

Share a calendar feed. An ICS link is a secret that never expires, works from any device, and cannot tell you who opened it. It also lags: most calendar apps refresh a subscribed feed every few hours.

Send screenshots or a daily email. It is safe, and it is out of date by the time anyone reads it.

What partners actually need is a window: one that is live, sits inside the tool they already work in, and that you can narrow or close at any time.

What a calendar embed looks like

A calendar embed is your practice's schedule in day, week, month or agenda view, placed inside another product: a CRM, an intranet, a partner portal or a website. It uses your colors, starts the week on the day you choose, shows the hours you set, and switches between English and Spanish.

Appointments are colored by provider, service or status. Clicking one can open a small read-only panel, or it can simply tell the host page which appointment was clicked. If you create appointments through our REST API with your own external_id, that id comes back in the click event, so the CRM can open its own record for that appointment. Nobody has to copy anything across.

You decide how much they see

The most important setting is the detail level, and there are three of them.

Busy only shows that a time is taken, and by which provider. That is enough for a call center to say “Thursday at 10 is free” without learning anything about your patients. Service adds what kind of appointment it is and whether it is confirmed, which is usually right for a team board or an operations screen. Full adds the patient's name, email and phone, for the cases where a trusted partner genuinely coordinates care with you. Every time a full-detail calendar is shown, it is written to your audit log together with the person who was looking.

Some things are never shown, at any level: appointment notes, intake answers, medications, conditions, insurance, date of birth and address. They are not hidden in the browser. The embed never reads those fields from the database in the first place.

Safe by design, not by configuration

The obvious way to build this kind of feature is to give partners a public link. We deliberately did not do that. Calendar embeds have no public mode: every view needs a short-lived session that your own server asks for.

In practice it works like this. Your server holds an API key that can do exactly one thing: open embed sessions. When one of your users opens the page, your server confirms who they are and asks Genkō for a token, which lasts 15 minutes by default and never more than an hour. The browser only ever sees that token, and the small loader script renews it before it runs out.

Each embed also lists the exact websites allowed to show it, for example https://crm.example.com. Paste the calendar anywhere else and it refuses to load. Genkō checks the site again on every request, and it also checks that the embed is still active, that the key is still valid and that your organization is still on the right plan. So the off switch takes effect straight away: revoke the key, disable the embed or remove a site, and open sessions stop working on their next request.

Setting one up takes an afternoon

Embeds are managed from Settings → Calendar embeds. You start from a preset (a team agenda, a single provider's calendar, or a busy-only board), adjust it, and watch a live preview update as you go. The preview shows exactly what your partner will see, so nothing is guesswork.

Before you share anything, paste the address of the page where the calendar will appear into the origin test. It tells you straight away whether that page is allowed. Then copy the snippet:

<div id="genko-calendar"></div>
<script src="https://www.getgenko.com/embed.js"></script>
<script>
  Genko.embed.mount(document.getElementById('genko-calendar'), {
    embed: 'emb_…',
    getToken: () => fetch('/genko/embed-token', { method: 'POST' })
      .then((r) => r.json()).then((d) => d.token),
  })
</script>

Your developer adds one small endpoint on your server that exchanges the key for a token. The builder has ready-to-run versions in Node, PHP, Python and curl. Some CRMs strip out scripts; for those, there is a plain iframe version you render on your own server.

Where practices are using it

Referral partners. A busy-only board inside a partner clinic's system replaces the “do you have anything this week?” phone call. Their coordinator sees the openings and books through the channel you already use for referrals.

Call centers and central booking teams. Agents get one calendar per location inside the CRM where they already log calls, so nobody switches tabs mid-call.

Your own CRM. Sales and account teams see the schedule next to the contact record. Clicking an appointment opens their own record of it, through the external_id you set when you created it.

Multi-location groups. Head office runs one embed per partner or audience and narrows each session to a provider or a view when it is opened. That way ten embeds cover far more than ten screens.

What it deliberately does not do

A calendar embed does not book appointments. Patients book through your patient portal or the website chat widget, which are built for the public. The embed is a view of the schedule for staff and partners, and keeping it read-only is what lets you share it without worrying.

Confirming, rescheduling and cancelling from inside the embed are on the roadmap. The settings already have room for them, so when they arrive you will switch them on for an existing embed instead of building a new one. A public mode and custom CSS are not planned. Both would weaken the guarantees described above.