Akute Has No Confirmed Status. Design For It.

The key is created from the Settings-Developer tab and displayed once. Akute's documentation is blunt about what happens next: "We do not provide the API key again if you lose it. Instead, we will deprecate that key and provide a new one on request."

Read that as an operational instruction, not a disclaimer. A key that can't be re-read is a key that must go into your secret store during the same session it was created, by the person who created it, before that browser tab closes. The failure mode isn't dramatic. Somebody screenshots it into a chat thread, or pastes it into a ticket, and now your credential is in a system with different retention rules than the one you built.

There's a plan dimension too. Akute's help documentation points you at support if you want to upgrade to a developer plan, and API access is gated behind a sufficient tier rather than available on every account. When we asked Akute about this directly in July 2026, they confirmed there's no charge for API access to either the practice or the integration partner. The practice just has to be on a plan that includes it, and a partner key gets coordinated when you move to production.

That combination is unusual enough to say plainly: no developer program, no marketplace review, no per-call metering, no revenue share. Compared to the five-figure entry fees elsewhere in this series, Akute's door is open.

Here is what will actually shape your build: Akute has no concept of a confirmed appointment.

That's a strong claim, so here is how it holds up. Akute publishes its collection through Postman, ninety-four endpoints of it, and appointments are well covered: GET, POST, PUT and DELETE on /v1/appointments, plus GET /v1/appointment_types. An appointment carries id, start_time, end_time, description, status, patient_id, external_patient_id, practitioner_user_id, video_url, appointment_type_id and appointment_type_name. The status field is writable through PUT, and the values the documentation demonstrates are booked and arrived.

So the write path exists. What doesn't exist is the state. Search that entire published collection for the string "confirm" and it returns nothing: not an endpoint, not a field, not an example value. The appointment exists, the patient either shows up or doesn't, and the space between those two states, which is exactly where reminder software lives, has no representation in the record.

If you've built against an EHR with a rich status vocabulary, this reads as a gap. It's worth resisting that reaction for a moment, because a confirmed field is a stranger concept than it looks.

In most systems, a confirmation status conflates three different facts: that you sent a message, that the patient responded, and that a human believes the patient is coming. Those aren't the same thing and they don't fail together. A patient can confirm and no-show. A patient can never reply and arrive early. An automated reminder marked confirmed because a delivery receipt came back records nothing about the patient at all.

EHRs that offer the field rarely define which of the three it means, and practices fill it inconsistently as a result. Akute declining to offer it is at least honest about the ambiguity.

The practical consequence for you is specific: the confirmation lives in your system, permanently, and it is not a temporary state you're holding until the EHR catches up. Build it as a first-class record with its own identity: which appointment it refers to, which message produced it, what the patient actually said, when they said it, and through which channel. That record is the artifact. Nothing gets mirrored back into Akute because there is nowhere to put it.

This is where projects go wrong, and it isn't a technical problem.

Front-desk staff look at the schedule in the EHR. That's their working surface, the screen that's open all day. If confirmations live in a dashboard they don't have open, the information may as well not exist. They'll phone the patient who already confirmed by text two hours ago, which is worse than not having reminders at all, because now the practice is annoying people and paying for the privilege.

Three ways to close that gap, in rough order of how well they hold up:

• Write to a field that does exist. description is free text on the appointment and it's writable through PUT, so a short standardized line in the same format every time, with a timestamp, turns your confirmation into something visible on the screen staff already use. This is a workaround and should look like one: predictable enough to scan, never something a human would mistake for a clinician's note.
• Push, don't pull. A morning digest of the day's confirmations and non-responses, delivered where the practice already reads things, beats a dashboard nobody opens. Unglamorous, and it works.
• Make silence the signal. Rather than surfacing everyone who confirmed, surface only the shrinking list of people who haven't. That's the list a human should act on, it gets shorter through the morning, and it's a much smaller thing to keep in view.

Whichever you pick, decide it with the practice before you build, and watch what the front desk actually does for a day first. The failure here is never that the data was wrong.

Akute's developer documentation lives at developer.akutehealth.com, and it's a live target. Their help documentation states they are continually adding more APIs and webhooks, and explicitly invites you to ask about endpoints that aren't documented yet.

Take that invitation seriously. It's rarer than it sounds. Most vendors in this series treat their published surface as the complete and final answer. Akute treating it as a starting point means the right first move is a conversation, not an afternoon of reading. Ask directly about appointment reads, availability, and webhooks for schedule changes before you design around what's currently on the page.

It also means the field list above is a snapshot. Pull the collection yourself the week you start, and treat any difference as news rather than as an error in one of the two.

This page draws on Akute's public help documentation, on the collection published from their developer site, and on direct correspondence with Akute in July 2026. The endpoint and field detail comes from that published collection as it stood in August 2026.

The absence of a confirmation concept is the load-bearing claim. It's true of what Akute publishes, which is not quite the same as being true of what Akute has built, so re-verify before you design around it. This is exactly the kind of thing a vendor adds without announcing.

Plan requirements and tier names change. Confirm current terms with Akute rather than with this page.