Deactivate a messaging campaign

Deactivate an existing messaging campaign

Use this route when an account-owned campaign is being retired. Keep its campaign ID for reconciliation and history. For content corrections or consent-text updates, use Update a messaging campaign instead.

Authenticate with an enabled API account over HTTPS from a permitted source IP address. Read the campaign first and check the associated brand and sending numbers. Deactivation changes the registration; it does not create a replacement campaign or move numbers to another campaign.

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/campaign/$CAMPAIGN_ID"

Remove the affected number assignments first

The public campaign DELETE does not detach phone numbers from the messaging carrier or clear their local assignment. Use the number-to-campaign removal workflow for each affected account-owned number, then verify its assignment. Removing an assignment does not release the phone number.

The portal’s broader Delete brand workflow performs its campaign and number cleanup before deleting that brand. Do not use that action when you intend to keep the brand and its other campaigns. The current ordinary campaign editor does not offer a separate campaign-delete button equivalent to this direct API route.

Submit the intended deactivation

After reviewing the campaign ID and affected sending setup, send DELETE with no JSON body:

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request DELETE \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  "https://api.multitel.net/tcr/v2/campaign/$CAMPAIGN_ID"

The documented successful response is HTTP 204 with an empty body. Inspect the HTTP status rather than expecting a JSON status/response envelope. On accepted deletion, the current service marks the campaign resource deleted and expired locally and marks its legacy campaign record expired. It does not cascade deletion to the brand.

Use one idempotency key for this intended request and preserve the exact method, path, query and body bytes for replay. A processing duplicate can return 409 with Retry-After; completed requests can replay the stored result. A cached error or interrupted connection does not establish whether the registry has already acted. Retain the campaign ID and requestId when present.

Verify both registration and assignments

Check the campaign’s current state and the affected numbers in the portal after the request. The API may retain local ownership metadata after retirement so an owned identifier can still be checked; do not infer that the same ID must always return a local 404. The registry decides the returned status or availability of the retired record.

If a number remains assigned, reconcile that existing assignment. Do not create another campaign simply to retry deactivation or assume an HTTP 204 proves carrier cleanup happened. If local synchronization fails after the registry accepts the request, the API can return 500 even though the external deactivation already occurred.

Retirement is separate from an account settlement

The current DELETE service does not dispatch an immediate campaign-registration debit. This does not promise a refund, erase an existing commitment or release rented numbers. Check the account’s campaign terms and outstanding invoices in the portal. Number rental and message usage are separate from campaign registration.

If the entire business registration is being retired after its campaigns and assignments have been reconciled, continue with brand retirement.