Delete a sender profile

Deletes one of your sender profiles and returns 204.

The delete is soft: the profile stops being usable and stops appearing in reads, and its message history is kept, because deleting a profile must not delete the record of what it sent.

What it releases

Anything the profile still held goes with it. A phone number returns to our inventory and can be given to whoever asks next — it does not stay reserved for you, and getting the same number back afterwards is not something we can promise. A WhatsApp account of its own is deregistered from Meta. Its routing rules stop being used, so nothing sends through the profile after this call.

A profile that only inherits from its organization holds nothing of its own and releases nothing.

When it is refused

A number the profile holds that your WhatsApp Business Account still carries refuses the delete with a 409 CONFLICT_012, and nothing is deleted: it would return to our shared inventory while Meta still routes WhatsApp to it, and the next customer given it could not register it at all. Only you can take it off the account — deregister and delete it in WhatsApp Manager, then try again. A 409 CONFLICT_013 means we could not read the account, so we cannot tell either way.

DELETE
/v3/sender-profiles/{id}

Response Body

application/json

application/json

application/json

application/json

curl -X DELETE "https://example.com/v3/sender-profiles/497f6eca-6276-4993-bfeb-53cbbbba6f08"
Empty
Empty
{
  "success": true,
  "error": {
    "code": "string",
    "message": "string",
    "details": {
      "property1": [
        "string"
      ],
      "property2": [
        "string"
      ]
    },
    "doc_url": "string"
  },
  "meta": {
    "request_id": "string",
    "timestamp": "2019-08-24T14:15:22Z",
    "version": "string"
  }
}
{
  "success": true,
  "error": {
    "code": "string",
    "message": "string",
    "details": {
      "property1": [
        "string"
      ],
      "property2": [
        "string"
      ]
    },
    "doc_url": "string"
  },
  "meta": {
    "request_id": "string",
    "timestamp": "2019-08-24T14:15:22Z",
    "version": "string"
  }
}
{
  "success": true,
  "error": {
    "code": "string",
    "message": "string",
    "details": {
      "property1": [
        "string"
      ],
      "property2": [
        "string"
      ]
    },
    "doc_url": "string"
  },
  "meta": {
    "request_id": "string",
    "timestamp": "2019-08-24T14:15:22Z",
    "version": "string"
  }
}
{
  "success": true,
  "error": {
    "code": "string",
    "message": "string",
    "details": {
      "property1": [
        "string"
      ],
      "property2": [
        "string"
      ]
    },
    "doc_url": "string"
  },
  "meta": {
    "request_id": "string",
    "timestamp": "2019-08-24T14:15:22Z",
    "version": "string"
  }
}

Update a sender profile PATCH

Changes a profile's own attributes: `name`, `short_name`, `description` and `notifications` (who is emailed about the profile's events — `ORGANIZATION`, `SENDER_PROFILE`, or `ORGANIZATION_AND_SENDER_PROFILE`). **Only those.** A profile's identity, its markets and its compliance each have a sub-resource of their own, because each has its own validation and its own external consequences — a brand change may need re-registering, a market change provisions a sender. Folding them in here would give those fields two writers and no way to say which one wins. Omitting a field leaves it alone; sending `null` clears it. Those are different requests, so `{}` changes nothing and is refused rather than silently accepted — a caller who misspelt every field would otherwise get a `200` and an unchanged profile. `name` and `short_name` cannot be cleared: `short_name` is the SMS sender id, so a supplied value must be 3–11 characters of letters, numbers and spaces with at least one letter. Returns the profile as `GET /v3/sender-profiles/{id}` would, so the result of the change needs no second call to see.

Get your channels GET

Every market you send SMS in, your WhatsApp account, your RCS agent and the numbers you carry phone calls on — with each one's status, and what each market has supplied. **Status lives on the channel, never on you or your brand.** An identity has no lifecycle; what has one is the registration of a sender in a market and the approval of a channel. So a customer live in one country and mid-registration in another reports exactly that, rather than one flattened answer. `sms[n].compliance` carries what each market holds: `brand` and `campaign` for markets that register with a compliance regime such as US TEN_DLC, and `documents` for markets that pre-register an alphanumeric or similar sender. Absent means the market registers with nobody and nothing has been supplied. `GET /v3/compliance/requirements` says what a market demands of any new customer; this says what you gave it. Send `x-profile-id` with an organization key to read one of your profiles' channels.