Changelog

2026-10-07: Self-serve webhook events are picked from the Entity dropdown

• Opting in to clinicalDataAdded and aiResearchCompleted moved. On the Notifications tab both events are now picked from the Events group of the subscription builder’s Entity dropdown, when creating an endpoint and when adding to one, instead of being ticked in a separate Other events list. An endpoint can carry either event alone or alongside its subscriptions, and each one is listed with them on the endpoint and removed the same way. Delivery is unchanged.

2026-10-06: Companies report whether in-network requests are enabled

• New company.inNetworkRequestEnabled field. Every browse endpoint that can select or filter on the company now accepts and returns inNetworkRequestEnabled, a boolean saying whether the company is approved to use in-network requests. It is false until Hermes staff turn it on, alongside recordRequestEnabled.

2026-10-06: Webhooks subscribe to named events

New webhook endpoints subscribe to named events instead of picking table columns. Events are grouped by product capability and named group.event, such as recordRequest.completed, siteSonar.completed or authorization.approved; ticking a group subscribes to every event in it. Each group sends one fixed, documented data payload, and every delivery carries "version": "events". One endpoint-level scope (which projects, whose records) replaces the per-subscription scope.

siteSonar.completed, patientHistories.completed and ehrSearch.completed are sent when a run finishes, whatever the result, so repeating a search that ends the same way still sends an event.

clinicalData.added and aiResearch.completed are now signed with a timestamp, carry X-Webhook-Id, and are retried like every other event.

Existing endpoints become Classic endpoints and keep receiving exactly the deliveries they did, with no version field; the Classic webhooks entries are marked deprecated. No new Classic endpoint can be created. Each Classic endpoint offers Upgrade to Events in the web app, with a preview of how its subscriptions map.

2026-10-06: Joined columns keep their access rules; site tax ID is Hermes-only

• A Hermes-only column stays Hermes-only when a browse reaches it through a join. A column the API withholds from your account on its own browse (for example visit.dataSources on POST /v0/visits/browse) is now withheld the same way when another browse joins to it, such as visit on POST /v0/procedures/browse or labAccession.orderingPhysicianSite on POST /v0/lab-results/browse. Selecting it returns no value, and a filter, sort or aggregate on it is ignored rather than applied.
• A site’s taxId is no longer returned. The site tax identification number is now Hermes-only wherever the API returns a site. That covers GET /v0/sites/{site_id} (including its reference half), GET /v0/sites/random, POST /v0/sites, PUT and PATCH /v0/sites/{site_id}, POST /v0/sites/{site_id}/research, the site-finder job and record-request site finder responses, and the site embedded in record-request responses. On those routes taxId reads as an empty string. On every browse that joins a site the column is still accepted in a select, filter or sort, and is ignored.

2026-10-06: Embed tokens without parentOrigin deprecated; parentOrigin checked strictly

• Minting a write-capable embed token without parentOrigin is deprecated. This covers the auth-intake, site finder and clinical-data embed-token routes. A mint without it still succeeds and keeps today’s behavior (any page may frame the iframe, and the clinical-data iframe posts its browse state to any parent), but a later release will require parentOrigin and answer a mint without it with 400. Send it now.
• parentOrigin is checked more strictly. It must be one exact https://host[:port] origin: a wildcard host (https://*.example.com), credentials, a path, query or fragment, or whitespace, control characters or backslashes inside the value is answered with 400, as is any origin not on your approved list. An approved origin written plainly, as https://host[:port], is accepted exactly as before, and leading or trailing whitespace around it is still ignored.
• Guides: the site finder guide now shows sending parentOrigin, and both embed guides mark leaving it out as deprecated.

2026-10-05: Webhook event schemas for clinical data added and AI research completed

• clinicalDataAdded and aiResearchCompleted are in the spec. The top-level webhooks section now documents both events alongside the subscription events, with the two-field eventType / data body each is delivered with and the schema of its payload: ClinicalDataAddedPayload (with its per-type counts and source) and AiResearchCompletedPayload. Neither delivery changed; only its documentation is new.
• Each subscription event’s body names its own eventType. The envelope every subscription delivery carries is unchanged, and its eventType is now published as the one value that entry delivers rather than as any string.
• source can be parsePass. A clinicalDataAdded delivery already reported parsePass for content surfaced by re-reading clinical data Hermes holds; the reference now lists it beside siteSonar, patientHistories and sandboxSearch.
• Guides: ccda is optional when creating a record request and defaults to false; the guide used to call all four deliverable flags required. The browse aggregation example no longer asks for min and max of visit service dates, which the API rejects: those aggregates take numeric columns only.

2026-10-05: Purpose alignment judged against the project’s purpose; dates of service pass on coverage

• purposeAlignment is judged against the project’s purpose. The verdicts.purposeAlignment item on GET and PUT /v0/auth-check/{filename}, on the patient and record-request authorization reads, and on the project letter responses compares the form’s classified authorizationPurpose with the purpose of the project the document belongs to, no longer with the set of purposes the company is authorized for. A General grant passes, a different purpose fails naming both, and a project with no purpose fails every classified form. The item stays null for an analysis without a classification and for a standalone submission, which belongs to no project.
• Minting a signing link needs the project’s purpose. The /auth-intake/embed-token routes answer 400 with Project purpose is required for a project that names none; the generated authorization states that purpose.
• Dates of Service passes when the form’s range covers the request’s. The check used to require the form’s start and end to equal the request’s, so a form granting 2015 to present failed a request for 2020 to 2023. A covering range now passes. A failure names the side the form does not cover, for example startDateOfService: request starts 2018-01-01, before the form's start 2020-01-01.

2026-10-04: Deleting a patient’s authorization answers 404 for an unknown patient

• Deleting a patient’s authorization now answers 404 for an unknown patient. DELETE /v0/companies/{companyId}/projects/{projectId}/patients/{patientId}/authorization used to answer 200 whatever the patient, even when no such patient existed. It now answers 404 when the patient does not exist or is not visible to the caller, and deletes the document only for a patient the caller can see. For a patient that exists, the call is unchanged, including the 200 when no document is on file.

2026-10-04: Browse columns and value formats described

The API itself is unchanged; these are changes to what the reference and the spec describe.

• Browse columns are described wherever they appear. A column’s description used to be published only on the row it is returned in. The same sentence is now on that column in every browse request schema: the filter (where), the field selection (select), the sort, and the numeric aggregates. The keys that name an entity or a joined entity inside where, select and orderBy are described too, including the isNull / isNotNull shorthand a joined entity’s filter accepts.
• Validated values document their format. Each value type the API checks, such as a ZIP code, a US state, a person’s name, a phone number, a date of birth or an identifier, now states in the spec what it accepts, how it is normalized, and that any other value is rejected. The reference repeats those rules under every field of that type, in the HTML pages and in their Markdown versions.

2026-10-04: Machine-readable docs, deprecation flags and documented 401s

The API itself is unchanged except where noted; these are changes to what the reference publishes and how it can be read.

• Markdown and llms.txt. Every page of the reference and the guides is also served as Markdown at the same path with .md appended. /llms.txt lists them all, and /llms-full.txt is every guide and reference section in one file.
• Per-group spec slices. /api-docs/openapi/<tag>.json serves one endpoint group’s operations with only the schemas they use, for example /api-docs/openapi/patients.json.
• servers. The spec now declares https://api.hermeshealth.ai as its server, and no longer publishes a blank license.
• Deprecation flags. These fields are marked deprecated: true. They still work; read the replacement in new code:
  • siteSonarStatus on the patient response: read searchStatus.
  • hipaaAuthorization on the patient output: read authorization.
  • zipCode on the patient response and the patient form: use zipCodes.
  • lastName on the patient form: use lastNames.
  • isSandbox on the project form: use status.
  • siteAddress on the record request form: use siteAddressLine1 and siteAddressLine2.
• lastNames, zipCodes and cityStates are in the patient form schema. The routes always accepted them; the published request body had left them out.
• 401 on every authenticated route. Twenty-six operations now document their 401 response. On those routes a 401 raised while handling the request used to be answered as a 500; it is now answered as a 401.
• recordRequest.followUpDue webhook. The event was already delivered and is now listed under the spec’s webhooks.
• Descriptions and examples. Every operation, path parameter, enum and customer-facing field has a description; enum values list what each one means and which statuses are terminal. Patients, record requests, projects, sites, files and notes carry example values.