Webhook Maintenance: Pause Workers, Deactivate, or Delete?

For routine downstream maintenance, keep your webhook receiver verifying and storing events, and pause the application workers that consume them. Deactivating a UnifyPort endpoint sets its status to inactive without deleting its configuration; deleting removes the endpoint. Neither operation is a documented pause-and-replay service. Choose the control by what must stop, not by which button is easiest to reach.

Key takeaways

• Pause business processing behind durable intake when only the CRM, AI workflow, or worker needs maintenance.
• Use endpoint deactivation when making the endpoint inactive is intentional, with an explicit plan for a possible delivery gap.
• Reserve deletion for retiring the endpoint, not a temporary deployment.
• An HTTP 503 does not buy a maintenance window: UnifyPort retries immediately, without backoff.

Compare the three controls

The first row is an application architecture recommendation. The other two are documented UnifyPort control-plane operations.

Control	What changes	What remains your responsibility
Pause application workers	Your consumers stop processing; a healthy receiver continues durable intake	Queue capacity, retention, restart checkpoints, and duplicate-safe side effects
Deactivate the endpoint	Endpoint status becomes inactive; the endpoint is not deleted	Record the interruption, verify reactivation, and investigate any missing interval
Delete the endpoint	The endpoint resource is removed	Provision and verify a new endpoint if service is needed again

The Deactivate webhook endpoint reference documents POST /v1/webhook-endpoints/{endpoint_id}/deactivate. The Delete webhook endpoint reference documents DELETE /v1/webhook-endpoints/{endpoint_id}, returning 204 No Content on success.

These controls concern the webhook endpoint. Do not treat them as account logout, runtime shutdown, or cancellation of work already accepted by your application. A worker that has already claimed a job may still complete it; stopping those side effects requires your own processing controls.

When pausing workers is the better maintenance boundary

Suppose your CRM integration needs a deployment while LINE and WhatsApp conversations should keep entering the inbox. This is a hypothetical design scenario, not a reported customer result.

Keep the receiving path independent of the CRM:

1. Verify the signature and timestamp against the raw request bytes.
2. Validate and commit the event to durable storage.
3. Return a successful acknowledgement.
4. Let separate workers perform CRM writes, AI calls, or notifications.

Before pausing consumers, verify that the intake store can remain available throughout the work. Set operational limits for queue growth and retention, and define who responds if storage fails. An in-memory array is not a maintenance buffer that survives a process restart.

After the deployment, resume from committed processing state. Do not mark the entire backlog complete just because ingress returned 2xx. For the initial storage boundary, see the webhook-first integration checklist; maintenance adds a separate decision about when consumers may act.

This pattern does not solve maintenance of the intake store itself. If both receiver and storage must become unavailable, plan a resilient intake replacement or explicitly accept and document the interruption. Do not advertise uninterrupted collection without a verified design.

Why failed responses are not a pause mechanism

The delivery contract says connection errors and 408, 429, and 5xx responses are retried immediately. retry_policy.max_attempts counts retries after the initial request; the default is three retries. There is no backoff, and Retry-After is not honored. Other 4xx responses stop automatic delivery and mark the event as dead-lettered.

Consequently, returning 503 throughout a deployment can exhaust attempts rather than defer them until your service is ready. Returning 200 while discarding the payload is worse: it acknowledges work you did not durably accept. A dead-lettered event is not a promise of a public replay operation.

Keep signature verification enabled during maintenance. An empty signing_secret disables signing; it does not pause delivery. If credentials must change, use the separate signing-secret rotation procedure rather than combining an authentication change with endpoint retirement.

If you intentionally deactivate, use explicit recovery gates

Before changing anything, use Get webhook endpoint to record the endpoint ID, URL, status, subscriptions, signing state, and retry policy. Keep the actual signing secret in protected configuration, not the change log. Identify which downstream workflows depend on this endpoint.

Then deactivate the selected endpoint and read back its status. Record the operation time and the result separately from application queue state. The public reference does not specify a drain guarantee for requests already in flight or replay of events from an inactive interval. Do not infer either from a successful response.

To resume, use Update webhook endpoint with status: active and the reviewed configuration. Preserve the intended URL, subscriptions, retry policy, and nonempty signing secret; do not copy an illustrative inactive or unsigned configuration into production.

Read back the result, confirm signing_enabled: true, and send a controlled message to a connected messaging account. Trace the resulting message.received event through signature verification, durable storage, and the intended worker. This proves a fresh path works; it does not prove that the inactive interval was recovered.

If a control-plane response times out, inspect the current endpoint before issuing further changes. Preserve request diagnostics without secrets. A quiet receiver alone is not proof that deactivation completed, and a successful reactivation response alone is not proof of end-to-end processing.

Retirement and recovery limits

Delete only after deciding the resource is no longer needed and documenting its dependants. Successful deletion has no JSON body to parse. Creating a replacement later is provisioning, not restoration of the old endpoint’s missed deliveries.

UnifyPort’s unofficial interface normalizes supported messaging-account events, but provides no general REST message-history read API or guaranteed replay of missed payloads. Limited WhatsApp history mechanisms are not a cross-channel maintenance recovery guarantee.

When resuming stored work, use the documented deduplication boundary: ordinary event retries reuse X-Device-Event-Id; conversation.history batches require message-level merging rather than global suppression by that header alone. Keep outbound business actions idempotent independently of ingress deduplication.

FAQ

Does deactivation preserve the endpoint?

Yes. It changes the status to inactive without deleting the endpoint. It does not establish a backlog retention or replay guarantee.

Can I pause just the AI workflow?

Yes, in your application design: pause that consumer while the receiver continues verified, durable intake. This is not an extra UnifyPort API setting.

Should I delete and recreate the endpoint for a deployment?

Usually not. Pause consumers for downstream maintenance, or plan an intentional endpoint interruption. Deletion is a retirement choice.

Next step and sources

Review the webhook delivery contract and write down which layer your maintenance actually stops before changing production configuration.

Product references checked on 2026-10-06:

• Deactivate webhook endpoint
• Update webhook endpoint
• Delete webhook endpoint
• Delivery, acknowledgements, and retries