---
title: "Delete or Cancel a Appointment resource by id"
method: DELETE
path: "/Appointment/{id}"
tags: ["Booking"]
---

# Delete or Cancel a Appointment resource by id

`DELETE /Appointment/{id}`

Delete or Cancel a single Appointment resource.

## Path parameters

- `id` string, uuid, required

## Headers

- `X-Request-Id` string, uuid, required
- `X-Correlation-Id` string, uuid, required
- `NHSD-Target-Identifier` string, byte, required — Identifier
- `NHSD-End-User-Organisation` string, byte, required — Requesting Organization described in an object based on a FHIR 'Organization' resource (Standard Base64 encoded JSON). Different BaRS Applications may have different standards and requirements for the Access Control which these headers are used for. In this example an ODS code and the Organisation name is provided. Other identifiers are permitted if required.
- `NHSD-Requesting-Practitioner` string, byte — Requesting Practitioner described in an object based on a FHIR 'PractitionerRole' resource (Standard Base64 encoded JSON). This item is not mandatory, however if the information is available it must be included in the request. Only in the event that it is not available, should it be omitted. The example below shows a General Practitioner and their SDS Role profile Id. The Base64 encoded example below shows a General Practitioner and their SDS Role profile Id.
- `NHSD-Requesting-Software` string, byte, required — Requesting Software described in an object based on a FHIR 'Device' resource (Standard Base64 encoded JSON). Different BaRS Applications may have different standards and requirements for the Access Control which these headers are used for. The identifier used here, though arbitrary, should be consistent across instances of a product, the name and version of the product should also be accurate and consistent.
- `Accept` string, required
- `use-context` string, required

## Response `200`

Successful response

## Other responses

- `4XX` — Below are examples of potential HTTP status codes and their associated error codes, which could be returned in the event of a fault. Guidance on error handling within BaRS can be found [here](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core/1.4.0/Error-Handling). | HTTP status | Error code | Description | | ----------- | -------------------------- | --------------------------------------------- | | 400 | SEND_BAD_REQUEST | The API was unable to process the request. | | 400 | REC_BAD_REQUEST | The Receiver has responded stating the message was malformed. | | 401 | SEND_UNAUTHORIZED | The API deemed you unauthorized to make this request. | | 401 | REC_UNAUTHORIZED | The receiver deemed you unauthorized to make request. | | 403 | SEND_FORBIDDEN | Missing or Expired Token. | | 404 | PROXY_NOT_FOUND | No related people exist for given NHS number. | | 404 | REC_NOT_FOUND | Patient record for given NHS number has been invalidated and not superseded by another NHS number. | | 405 | SEND_METHOD_NOT_ALLOWED | HTTP Verb is not correct for this scenario.| | 405 | REC_METHOD_NOT_ALLOWED | Receiver does not allow this.| | 405 | PROXY_METHOD_NOT_ALLOWED | Proxy does not allow this.| | 406 | SEND_NOT_ACCEPTABLE | Senders message had an incorrect content type defined for a response.| | 408 | REC_TIMEOUT | The downstream domain processing has not completed within the configured timeout period. | | 409 | SEND_CONFLICT | | | 409 | REC_CONFLICT | | | 409 | PROXY_CONFLICT | | | 422 | SEND_UNPROCESSABLE_ENTITY | Message was not malformed but deemed unprocessable. | | 422 | REC_UNPROCESSABLE_ENTITY | Message was not malformed but deemed unprocessable. | | 422 | PROXY_UNPROCESSABLE_ENTITY | Message was not malformed but deemed unprocessable. | | 429 | SEND_TOO_MANY_REQUESTS | The user has sent too many requests in a given amount of time| | 429 | REC_TOO_MANY_REQUESTS | The user has sent too many requests in a given amount of time|
- `5XX` — Below are examples of potential HTTP status codes and their associated error codes, which could be returned in the event of a fault. Guidance on error handling within BaRS can be found [here](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core/1.4.0/Error-Handling). | HTTP status | Error code | Description | | ----------- | -------------------------- | --------------------------------------------- | | 500 | REC_SERVER_ERROR | The receiver server has encountered an Error processing the request. | | 500 | PROXY_SERVER_ERROR | Proxy Error. | | 501 | SEND_NOT_IMPLEMENTED | The Request was not recognized. | | 501 | REC_NOT_IMPLEMENTED | The Receiver did not recognize the request. | | 501 | PROXY_NOT_IMPLEMENTED | The Proxy did not recognize the request. | | 503 | REC_UNAVAILABLE | The Receiver was unavailable to service the request.| | 503 | PROXY_UNAVAILABLE | The Proxy was unavailable to service the request. |

---

[API](https://skmtc.net/nhs/apis/booking-and-referral-fhir-api.md) · [All operations](https://skmtc.net/nhs/apis/booking-and-referral-fhir-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/nhs/booking-and-referral-fhir-api/revisions/5ebb9de06e11/schema)