Delete a UnifyPort Messaging Account: Handle 202 vs 204
Deleting a UnifyPort messaging account can return 204 No Content or 202 Accepted. Quota deletion completes with 204; wallet deletion returns 202 while provider cleanup and any refund continue asynchronously. For 202, save the returned operation_id and query the billing operation. An account disappearing from the current list does not prove cleanup or a refund finished.
Key takeaways
- Choose deletion only when retiring the messaging account, not simply pausing its connection.
- Branch on the actual HTTP status before parsing JSON: 204 has no response body.
- Preserve the operation identifier from 202 independently of the account list.
REVIEWmeans unconfirmed; it is not proof of a refund.
First decide whether the account should be deleted
The Stop runtime reference describes a different action: it stops the runtime without deleting the account. If your goal is temporary connection control, choose that boundary instead. When bringing a retained account online again, follow the runtime recovery runbook rather than treating deletion as a restart tool.
If only a CRM or AI worker needs maintenance, neither account deletion nor runtime shutdown is necessarily appropriate. The webhook maintenance comparison explains how to keep verified intake running while application consumers pause.
This article concerns the UnifyPort account resource. It does not describe deleting the user’s native Telegram, WhatsApp, or LINE identity, erasing your CRM records, or cancelling work already claimed by your workers.
Match the response to the deletion contract
The Delete account API reference defines DELETE /v1/accounts/{account_id} and both successful response paths:
| Response | Documented meaning | Application handling |
|---|---|---|
204 No Content | Quota deletion completed | Do not parse JSON; retain diagnostic response headers |
202 Accepted | Wallet deletion accepted; provider cleanup and any refund continue asynchronously | Save data.operation_id; query the operation separately |
| Timeout or unreadable response | The client cannot establish the outcome | Preserve uncertainty and reconcile before another mutation |
This distinction is consistent with RFC 9110’s DELETE semantics: acceptance is different from an enacted deletion with no further response content. Do not collapse both into a UI message saying “everything deleted and refunded.”
The account-list contract says accounts disappear after quota deletion completes or wallet deletion is accepted. List visibility is therefore not a completion monitor for the asynchronous branch.
Capture the result before removing the UI row
Recommended application preparation—not extra API fields—is to save the selected workspace context, account_id, provider, operator confirmation, and request time. Block new jobs for that account in your own application and decide how already-running work should be handled. An application gate is not a transactional guarantee that a previously submitted send can be cancelled.
The following illustrative Node.js function performs one deletion attempt. Supply a reviewed account ID and a server-side API key. It deliberately does not retry or claim to implement durable storage.
export async function deleteMessagingAccount(accountId, apiKey) {
const response = await fetch(
`https://api.unifyport.ai/v1/accounts/${encodeURIComponent(accountId)}`,
{ method: 'DELETE', headers: { 'X-Api-Key': apiKey } }
);
const requestId = response.headers.get('X-Request-Id');
if (response.status === 204) {
return { httpStatus: 204, requestId };
}
const body = await response.json();
if (response.status === 202 && body.data?.operation_id) {
return { httpStatus: 202, requestId, operation: body.data };
}
throw new Error(`Deletion needs reconciliation; HTTP ${response.status}`);
}The return keys httpStatus, requestId, and operation are local application names, not new UnifyPort response fields. Persist the result before discarding the account’s UI row. Catch network, parsing, and unexpected-response failures in the caller; none should silently become “deletion completed.” Preserve redacted error details for diagnosis.
Follow the operation, not the disappearing account
For a 202 response, use the saved identifier with Get account billing operation: GET /v1/account-operations/{operation_id} using the API key for the same workspace.
The documented accepted-deletion example includes operation_id, kind: DELETE, state: PENDING, and account_id. The operation query also documents state: REVIEW with last_error_code: cleanup_unconfirmed. REVIEW is unconfirmed and does not prove a refund. Display that uncertainty instead of translating it into success.
Keep a separate application record for operation observations so removing an account from a selector does not remove the tracking link. Choose a bounded polling policy and escalation rule for your application; this article does not assert a completion deadline or refund amount. If the initial response was lost and no operation identifier was saved, do not invent one from request_id or assume a list lookup recovers it. Retain the account ID, timestamps, and diagnostics for reconciliation.
For bodyless 204 responses, X-Request-Id is the diagnostic identifier. For the distinction between request tracing and business-operation tracking, see UnifyPort request ID tracing.
Acceptance checks and FAQ
Before enabling the control, test that 204 never triggers JSON parsing, 202 survives a page reload with its operation ID intact, and REVIEW stays visibly unresolved. A timeout should keep an investigation record, not trigger automatic recreation or repeated deletion.
Does stopping the runtime delete the messaging account?
No. Stop runtime explicitly preserves the account. Authentication and connection state are separate in the account lifecycle reference.
Is 202 a deletion failure?
No. It is acceptance of the asynchronous wallet deletion path, not proof that every associated step finished.
Does removal from the account list confirm a refund?
No. Wallet accounts disappear when deletion is accepted. Query the billing operation; do not infer a financial outcome from list visibility or REVIEW.
Next step and sources
Implement both response branches against the Delete account reference before connecting the destructive UI control. Handle application records and retention separately; this API is not a general data-erasure workflow.
Sources checked on 2026-10-30:
Turn messaging integration into a stable product pipeline.
Start by sending through one API, then bring every inbound message back into your business system with standard events.