SEsentdm
Profiles

Update profile settings

Changed on

Deprecated. This endpoint is replaced by /v3/sender-profiles and will be removed in a future release. It still behaves exactly as before, so nothing needs to change today — but new integrations should use /v3/sender-profiles, which models a profile's markets, compliance, brand, campaigns and billing explicitly.

Updates a profile's configuration and settings. Requires admin role in the organization. Only provided fields will be updated (partial update).

Brand Management

Include the optional brand field to create or update the brand associated with this profile. The brand holds KYC and TCR compliance data (legal business info, contact details, messaging vertical). Once a brand has been submitted to TCR it cannot be modified. Setting inherit_tcr_brand: true and providing brand in the same request is not allowed.

Payment Details

When billing_model is "profile" or "profile_and_organization" you may include a payment_details object containing the card number, expiry (MM/YY), CVC, and billing ZIP code. Payment details are never stored on our servers and are forwarded directly to the payment processor. Providing payment_details when billing_model is "organization" is not allowed.

Deprecated fields

sending_phone_number_profile_id and sending_whatsapp_number_profile_id are accepted and ignored. Sender borrowing is gone: a profile cannot send from another profile's number, because two profiles behind one sender makes an inbound reply and a delivery receipt ambiguous about whose they are.

Sending either changes nothing and still returns 200 — they are kept on the contract so an existing integration keeps working. Reads carry both keys too and always answer null, which is how you can confirm the value did not take.

Give the profile a sender of its own instead — POST /v3/channels/sms or POST /v3/channels/whatsapp, sent with the x-profile-id header naming it.

patch/v3/profiles/{profileId}

Request

  • Base URL
    https://api.sent.dm
  • URL
    https://api.sent.dm/v3/profiles/{profileId}
  • Auth
    • API key in header x-api-key
    • or HTTP bearer

Path parameters

profileIdstring uuid required

Profile ID from route parameter

Headers

Idempotency-Keystring

Unique key to ensure idempotent request processing. Must be 1-255 alphanumeric characters, hyphens, or underscores. Responses are cached for 24 hours per key per customer.

x-profile-idstring uuid

Profile UUID to scope the request to a child profile. Only organization API keys can use this header. The profile must belong to the calling organization.

Request body

sandboxboolean

Sandbox flag - when true, the operation is simulated without side effects Useful for testing integrations without actual execution

namestring nullable

Profile name (optional)

iconstring nullable

Profile icon URL (optional)

descriptionstring nullable

Profile description (optional)

short_namestring nullable

Profile short name/abbreviation (optional). Must be 3–11 characters, contain only letters, numbers, and spaces, and include at least one letter. Example: "SALES", "Mkt 2", "Support1".

inherit_tcr_brandboolean nullable

Whether this profile inherits TCR brand from organization (optional)

inherit_tcr_campaignboolean nullable

Whether this profile inherits TCR campaign from organization (optional)

billing_modelstring nullable

Billing model: profile, organization, or profile_and_organization (optional).

  • "organization": the organization's billing details are used; no profile-level billing info needed.
  • "profile": the profile is billed independently; billing_contact is required.
  • "profile_and_organization": the profile is billed first with the organization as fallback; billing_contact is required.
sending_phone_number_profile_idstring uuid nullable

Deprecated. Accepted and ignored. Sender borrowing is gone: a profile cannot send from another profile's SMS number. Supplying this changes nothing and the request still succeeds.

Bound rather than dropped so the property survives on the wire and in a generated client — an SDK that assigns it keeps compiling, which is the compatibility this exists for. It is deliberately not refused: a 400 here would break an integration that is otherwise working, and the capability it asks for is gone either way.

The trade-off, stated plainly. A caller asking for borrowing is told it succeeded when nothing happened. What makes that survivable is the read: sending_phone_number_profile_id comes back null on every profile, so a caller that checks its own write can see it did not take. Every request that carries one is logged, so we can tell when nobody is sending it any more and the field can go for real.

Give the profile a sender of its own instead: POST /v3/channels/sms with the x-profile-id header naming it.

sending_whatsapp_number_profile_idstring uuid nullable
allow_contact_sharingboolean nullable

Deprecated. Accepted and ignored. Contact and template sharing between sender profiles is gone — a profile sees only what it owns, and the organization still sees all of its profiles' contacts and templates through read-time widening. The four columns behind these flags were dropped by M260720120000.

Retired the same way as SendingPhoneNumberProfileId, and for the same reason: the properties stay bound so an SDK that assigns them keeps compiling, and a 400 would break a working integration over a capability that is gone regardless. Every profile reports all four as false, so a caller that checks its own write can see it did not take.

allow_template_sharingboolean nullable
inherit_contactsboolean nullable
inherit_templatesboolean nullable
sending_phone_numberstring nullable

Direct phone number for SMS sending (optional)

whatsapp_phone_numberstring nullable

Direct phone number for WhatsApp sending (optional)

allow_number_change_during_onboardingboolean nullable

Whether number changes are allowed during onboarding (optional)

Example request

{
  "name": "Sales Team - Updated",
  "description": "Updated sales department sender profile",
  "short_name": "SALES",
  "billing_model": "organization",
  "brand": {
    "contact": {
      "name": "John Smith",
      "businessName": "Acme Corp",
      "role": "CEO",
      "phone": "+12025551234",
      "email": "john@acmecorp.com",
      "phoneCountryCode": "1"
    },
    "business": {
      "legalName": "Acme Corporation LLC",
      "taxId": "12-3456789",
      "taxIdType": "us_ein",
      "entityType": "PRIVATE_PROFIT",
      "street": "123 Main Street",
      "city": "New York",
      "state": "NY",
      "postalCode": "10001",
      "country": "US",
      "url": "https://acmecorp.com",
      "countryOfRegistration": "US"
    },
    "compliance": {
      "vertical": "PROFESSIONAL",
      "brandRelationship": "SMALL_ACCOUNT",
      "isTcrApplication": true,
      "phoneNumberPrefix": "+1",
      "destinationCountries": [
        {
          "id": "US",
          "isMain": false
        }
      ]
    }
  },
  "sandbox": false
}

Response

Profile updated successfully

successboolean

Indicates whether the request was successful

Changes

  • 3eaea6f4015aRevision changes
    • info

      added the non-success response with the status

  • 6c829543a93eRevision changes
    • breaking

      added subschema #2: SentDmServicesEndpointsCustomerAPIv3ProfilesRequestsUpdateProfileRequest_Properties to the request body allOf list

    • breaking

      for the path request parameter profileId, the format changed from no format to uuid

    • breaking

      added to the response property oneOf list for the response status

    • breaking

      added to the response property oneOf list for the response status

    • breaking

      added to the response property oneOf list for the response status

    • breaking

      added to the response property oneOf list for the response status

    • warning

      removed subschema #2: SentDmServicesEndpointsCustomerAPIv3RequestsUpdateProfileRequest_Properties from the request body allOf list

    • info

      the endpoint scheme security BearerAuth was added to the API

    • info

      endpoint deprecated

    • info

      added to the response property allOf list for the response status

    • info

      added to the response property allOf list for the response status

    • info

      added to the response property allOf list for the response status

    • info

      added to the response property allOf list for the response status

    • info

      added to the response property allOf list for the response status

    • info

      removed from the response property allOf list for the response status

    • info

      removed from the response property allOf list for the response status

    • info

      removed from the response property allOf list for the response status

    • info

      removed from the response property allOf list for the response status

    • info

      removed from the response property allOf list for the response status

    • info

      removed from the response property oneOf list for the response status

    • info

      removed from the response property oneOf list for the response status

    • info

      removed from the response property oneOf list for the response status

    • info

      removed from the response property oneOf list for the response status