# Delete a data processing campaign

`DELETE /api/configuration/consent/data-processing/{all}`

- **Products:** Operator (`FOH`)
- **Features:** Front of House Generic Access (`FOHGENERIC`)

HTML version: [Delete a data processing campaign](https://support.gladstonesoftware.cloud/reference/configuration/delete-a-data-processing-campaign)

## Overview

Removes a data-processing campaign — a named purpose members grant or refuse consent for — from consent configuration. The final segment of the path is the campaign identifier returned when you [created the campaign](create-a-new-data-processing-campaign.md).

**This is a hard delete, and it discards every member's consent for the campaign.** The campaign goes, and so does every member consent record naming it, for all members and all channels. A history entry is recorded for each consent first — member, campaign, campaign name, channel, channel name and capture date — so the audit trail outlives the consent, but the consent itself is gone and re-creating a campaign with the same name will not bring it back.

**Deactivating instead of deleting does not save the consents.** Setting the campaign inactive through the update endpoint removes exactly the same member consent records; only the campaign itself survives. If you need to keep consent history usable, do neither.

**The route enforces the category, and a mismatch reads as `404`.** Data-processing and marketing campaigns share one identifier space, so this endpoint checks that the campaign you named is a data-processing one. Pass a marketing campaign's identifier here and you get `404`, not a `400` explaining the mistake — use the [marketing campaign delete](delete-a-marketing-campaign.md) for those.

A repeat call is not a no-op: it answers `404`, which on a retry means the first attempt succeeded.

On success, the next read of data-processing campaigns is up to date.

## Endpoint

`DELETE {base_url}/api/configuration/consent/data-processing/{all}`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Path parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `campaignId` | string | Yes | The campaign identifier — the generated code returned in the body when the campaign was created, or the identifier listed by the retrieve-campaigns endpoint. It is not the campaign's display name. Comparison is exact, and the campaign must be in the data-processing category: an unknown identifier and a marketing campaign's identifier both return `404`. |

## Sample request

```bash title="cURL"
curl -X DELETE '{base_url}/api/configuration/consent/data-processing/{all}' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | The campaign exists but is flagged as a system campaign and cannot be removed — `Cannot delete {campaignId} as this is a non removable campaign`. No consent records are touched. |
| `400` | Bad request | `campaignId` is empty — `A campaign ID must be supplied`. In practice a request with an empty path segment does not reach this endpoint. |
| `404` | Not found | No campaign has that identifier, or the campaign exists but belongs to the marketing category rather than data processing, or a previous delete already removed it. The body is empty, so `404` alone does not tell you which of these it was. |
| `500` | Internal server error | The delete failed — for example something still references the campaign. The consent removals, history entries and campaign removal are all-or-nothing, so nothing is left half-done. The body is empty. |