---
title: "HealthKit errorRequiredAuthorizationDenied: Clinical Records Are a Separate Class"
canonical: "https://aifitnessapi.com/fix/healthkit-required-authorization-denied"
cluster: "Troubleshooting"
primary_query: "healthkit errorrequiredauthorizationdenied"
last_reviewed: "2026-09-04"
description: "Required clinical record types fail as a block, and Apple does not say which one was refused. How to scope the requirement and degrade around a refusal."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"HealthKit errorRequiredAuthorizationDenied: Clinical Records Are a Separate Class\", AIFitnessAPI, https://aifitnessapi.com/fix/healthkit-required-authorization-denied"
---

# HealthKit errorRequiredAuthorizationDenied: Clinical Records Are a Separate Class

> Apple's documentation states that errorRequiredAuthorizationDenied means the user has not granted the application authorization to access all the required clinical record types. The load-bearing word is all: this is not one refused permission but an incomplete set. Apple's discussion adds that you specify those required clinical record types with an Info.plist key, so the requirement lives in your app's configuration rather than in the request itself. Because Apple states the system does not tell your app which record types were denied, the only real lever you have is declaring fewer required types and designing a path that still works without them.

- Canonical: https://aifitnessapi.com/fix/healthkit-required-authorization-denied
- Last reviewed: 2026-09-04
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "HealthKit errorRequiredAuthorizationDenied: Clinical Records Are a Separate Class", AIFitnessAPI, https://aifitnessapi.com/fix/healthkit-required-authorization-denied

---

Authorization succeeded in testing and fails for real users with `errorRequiredAuthorizationDenied`, and nothing you change in your request set seems to help. This case does not behave like the rest of HealthKit's permission model: it belongs to clinical record types, it is declared in your app's configuration rather than in the request itself, and it fails as a block rather than per type.

## What Apple documents

Apple's documentation states the abstract as: "The user hasn't granted the application authorization to access all the required clinical record types." The discussion is a single sentence:

> You can specify required clinical record types using the [required-read-authorization] Info.plist key.

The bracket is ours — Apple links the key by name and that label does not survive extraction to plain text. Apple's platform list introduces the case at iOS 12.0 and watchOS 5.0, later than the original accessing errors, which matches its scope: it exists for the clinical-records feature specifically.

Read the abstract closely, because the load-bearing word is **all**. This is not a report that a permission was refused. It is a report that the set you declared as required was not granted in full.

Two further points are documented by Apple and quoted in our [HealthKit authorization denied](/fix/healthkit-authorization-denied) guide: Apple says to specify three or more types under that key, and that when authorization fails this way, "the system doesn't tell your app which record types the person denied access to". So you learn that the requirement was not met, and nothing about which part of it failed.

## Why this is a separate authorization class

Ordinary HealthKit permissions are granular and independent. Each type has its own read and share decision, a refusal on one has no effect on another, and — as covered in the authorization guide — refusals on the read side are invisible by design. Required clinical types invert several of those properties at once.

| Property | Ordinary types | Required clinical types |
| --- | --- | --- |
| Where declared | In the authorization request | In the app's Info.plist |
| Granularity of failure | Per type | The whole declared set |
| What you learn on refusal | Nothing, on the read side | That the set was incomplete |
| Which type was refused | Not applicable | Apple states the system does not tell you |
| Recovery inside your app | None | None |

The practical consequence: this key is a hard product requirement expressed in configuration. Whatever you list there, you are declaring that your app cannot function without all of it, and the system enforces that literally.

## Diagnosis order

1. **Confirm the case.** `errorRequiredAuthorizationDenied` is not `errorAuthorizationDenied` and not `errorAuthorizationNotDetermined`. The first means a required set was incomplete; the second is a refused write; the third means you never asked, and is covered in [errorAuthorizationNotDetermined](/fix/healthkit-authorization-not-determined). If your logging collapses them, split it before anything else.
2. **Read your own declaration.** Open the built app's property list and read the required-types entry as shipped, not as you remember writing it. A list assembled during the build, or inherited from a template, is the usual surprise.
3. **Ask whether every entry is genuinely required.** This is the real question. Each type you list is another chance for a single refusal to fail the entire authorization for that user.
4. **Check Apple's minimum for the key.** Per the guidance quoted above, Apple says to specify three or more types.
5. **Segment your failures.** If the error is concentrated among users of one health system or record source, you are looking at record availability rather than at a code defect.

## Scope the requirement, then degrade around it

The only real lever you have is what you declare. As practice:

- **Declare the minimum that makes the app impossible without.** If a feature is enhanced by clinical records but not defined by them, those types do not belong in the required set. Requesting them normally means a refusal costs you one feature instead of the whole session.
- **Design a non-clinical path.** Activity, workout, and body-measurement data flow through the ordinary model, so an app whose core loop rests on those keeps working when the clinical request fails. The types available to you are catalogued in the [HealthKit identifier reference](/healthkit-identifiers).
- **Explain, then stop.** There is no API to change a permission on someone's behalf, and Apple states you are not told which type was refused, so your message can only be general: the app needs access to all of the requested health records, and that choice is made in the system permission flow. Do not name a specific record type you cannot know was the problem.
- **Do not re-prompt in a loop.** Once decisions have been made, re-requesting does not re-present the sheet — the documented behaviour is quoted in the [authorization denied](/fix/healthkit-authorization-denied) guide. A button that appears to do nothing is worse than a sentence of explanation.
- **Do not infer content from the failure.** The error tells you a permission set was incomplete. It tells you nothing about what any record contains, and nothing about the person. Treat the outcome as an access-control fact, full stop.

## Handling the data you do get

Clinical records raise handling questions that ordinary step counts do not. Before you ship, be clear on whether your handling of this data falls under health-privacy rules in your jurisdiction and what your obligations are — the starting points are [is fitness data PHI?](/compliance/is-fitness-data-phi) and [HIPAA compliance for a fitness app](/compliance/hipaa-compliance-fitness-app), and the store-review dimension is in [App Store health data rules](/compliance/app-store-health-data-rules). Those are engineering and policy questions, not clinical ones; nothing on this page is medical or legal advice.

## Symptom to action

| What you observe | Case | What to do |
| --- | --- | --- |
| Authorization fails for the whole clinical set | `errorRequiredAuthorizationDenied` | Narrow the required list; degrade |
| A save is refused | `errorAuthorizationDenied` | Stop saving that type |
| A call fails and you never requested | `errorAuthorizationNotDetermined` | Request first |
| Reads return only your own writes | Denied read, invisible by design | See the authorization guide |
| Every call fails on a managed device | `errorHealthDataRestricted` | See [MDM restriction](/fix/healthkit-data-restricted-mdm) |

## Where to go next

The full enum with Apple's own wording is in the [HealthKit error reference](/healthkit-errors), the permission model this case departs from is in [HealthKit authorization denied](/fix/healthkit-authorization-denied), and the surrounding setup is in the [HealthKit integration guide](/integrate/healthkit).

## FAQ

### Why does authorization fail even though the user allowed most types?

Because the required set is all or nothing. Apple's abstract states the user has not granted authorization to access all the required clinical record types, so a single refusal inside the declared set fails the whole authorization. Anything you list under that key is a hard requirement, and the system enforces it exactly as written.

[Permalink](https://aifitnessapi.com/fix/healthkit-required-authorization-denied#faq-1)

### Can I find out which clinical record type the user refused?

No. Apple states that the system does not tell your app which record types the person denied access to, which is quoted in our HealthKit authorization denied guide. That constrains your messaging: you can say the app needs access to all of the requested records, but you cannot name a specific one without guessing on the user's behalf.

[Permalink](https://aifitnessapi.com/fix/healthkit-required-authorization-denied#faq-2)

### How is this different from ordinary HealthKit authorization?

Ordinary types are declared in the request, decided independently, and refusals on the read side are invisible by design. Required clinical types are declared in the app's property list, fail as a set, and produce this error case when the set is incomplete. Same framework, a different authorization class with different failure behaviour.

[Permalink](https://aifitnessapi.com/fix/healthkit-required-authorization-denied#faq-3)