Skip to main content
Message redaction removes sensitive content from Message Detail Records (MDRs), message webhooks, and Telnyx reporting surfaces. Delivery metadata — status, timestamps, error codes, cost — remains available, though content-level investigation is restricted while redaction is on. Message redaction is enabled per messaging profile and requires activation on the organization. Contact support or the account team to have the organization added to the redaction allowlist before configuring profiles.

What redaction changes

When redaction is enabled on a profile, the following fields are redacted when retrieving messages via GET /v2/messages/ and in Telnyx reporting exports: Everything else is preserved, including the message ID, direction, status, delivery status, timestamps, error codes, carrier, line type, encoding, parts, cost, and TCR campaign information. Content hashes (text_hash, bytes_hash) are preserved in legacy v1 MDR responses.
Redaction applies at read time. The counterparty number is always masked on the side of the message that is external to Telnyx — the to number on outbound messages, the from number on inbound messages. The customer’s own Telnyx number on the other side of the record is never masked.

Redaction levels

The redaction_level setting controls whether inbound webhook payloads are also redacted: Delivery status webhooks (message.finalized events) are redacted whenever redaction is enabled, at any level: text, media, and subject are blanked and the destination phone number is masked. Delivery status fields themselves — status, timestamps, error codes — are unaffected.
MDR redaction applies identically at levels 1 and 2. Any level other than 2 disables webhook redaction but leaves MDRs redacted. Level 2 is the default and recommended setting.

Enable redaction

Once the organization is on the redaction allowlist, set the fields on a messaging profile:
Redaction is off (redaction_enabled: false) until explicitly enabled on the profile. Existing MDRs created before enabling redaction were stored unredacted and may still show full content when fetched.
Redaction controls what the Messages API and reporting surfaces return. It is applied when records are read, based on the redaction state captured when each message was sent — it is not a storage-level deletion of message content.

Disable redaction

Set redaction_enabled to false on the profile. Messages sent after the change produce unredacted MDRs. MDRs created while redaction was active remain redacted — redaction state is fixed at message creation time.
The redaction_enabled and redaction_level fields appear in API responses only for organizations on the redaction allowlist. For organizations not on the allowlist, the fields are absent from profile responses and values set via PATCH are ignored.

Troubleshooting

The organization is not on the redaction allowlist. The fields are silently dropped from update requests for non-allowlisted organizations (they do not error). Contact support to request activation, then retry the PATCH.
Redaction applies to messages sent after the profile change. MDRs created before redaction was enabled were stored with content and remain readable. Also verify the profile the message was sent on — redaction is per-profile, so traffic on other profiles is unaffected.
Confirm the webhook is an inbound message webhook (message.received event) and not another event type. Also confirm the message was sent to a number on a profile with redaction_level: 2 — level 1 leaves inbound message webhooks unredacted by design.
Delivery status events (message.finalized) do carry text, media, and subject fields, but when redaction is enabled those fields are blanked and the destination number is masked, at any level. If content is visible, the record predates redaction or the profile has redaction disabled.

Next steps

Message Detail Records

Understand MDR fields and status flows used alongside redaction.

Configurable Spend Limits

Cap daily spend per messaging profile.