Contact TextPulse SMS
Choose the request type first, then provide the route, account and message context needed to evaluate it. Account-specific questions should use the authenticated support option shown in the account or the contact method stated in the applicable commercial documents.
Request routing
A commercial route review needs different evidence from a delivery investigation or privacy request. Clear routing reduces handoffs and avoids exposing information that the receiving team does not need.
Share target countries, expected monthly volume, traffic purpose, sender preference, launch date, delivery-report needs and any procurement requirements. Current quotes and route records should control rate, coverage and sender decisions.
Use the authenticated support path. Include a sanitized request, exact response, message ID, UTC timestamp, destination context and the first unexpected state in the message lifecycle.
Identify the account, invoice or quote reference, currency, billing period and disputed event. Do not send payment credentials or unrelated customer data.
Contain exposed credentials first, preserve sanitized evidence and use the authorized account contact. State the affected account, discovery time, observed behavior and actions already taken.
Identify the relevant role, data category, request type, jurisdiction and account relationship. Use a proportionate identity-verification process and avoid attaching unnecessary personal data.
Provide message timing, sender, destination context, evidence of the unwanted behavior and any opt-out or complaint record. Do not publish recipient lists or sensitive content in a public channel.
Commercial brief
A request for “global SMS pricing” is too broad to support a production decision. Build a small route brief so the returned information can be tied to a country, sender, use case and effective date.
| Field | Why it matters | Useful level of detail |
|---|---|---|
| Destinations | Coverage, registration, rates and filtering vary by country and network. | Country list, approximate network mix and whether roaming users are relevant. |
| Traffic purpose | OTP, transactional and promotional traffic can follow different routes and rules. | Trigger, template examples and whether content is time-sensitive. |
| Sender requirement | Alphanumeric senders, long codes, short codes and shared origins are not interchangeable. | Preferred sender type, brand value and registration status. |
| Volume profile | Average volume alone does not show peak throughput or campaign concentration. | Monthly estimate, peak messages per second, burst shape and growth expectation. |
| Operations | Reporting, support and reconciliation affect implementation and commercial scope. | Webhook, delivery-report, invoice, support and launch requirements. |
| Effective date | Rates and route conditions can change. | Target launch date and required quote-validity period. |
Technical evidence
Describe the first point where observed behavior differs from the expected workflow. One well-documented example is more useful than a large collection of screenshots with no message identifiers or timezone.
Identify the affected workflow, start time, destinations, approximate failure rate and whether a safe workaround exists. Separate a launch blocker from a current production incident.
Record the sanitized request, HTTP result, provider status, message ID, final delivery state, callback events and application outcome using UTC timestamps.
Compare by country, mobile network, sender, template, encoding, route, time window and release version. State what still works as well as what fails.
Include application releases, credential rotation, sender approval, template changes, traffic growth, routing changes and webhook configuration updates.
Safe communication
Support and due-diligence records can become a secondary copy of sensitive data. Redact secrets and personal information before attaching logs, screenshots or message samples.
Expectations
This page explains how to prepare a request. It does not create support hours, response targets, escalation rights, route availability, pricing validity or service credits. Those items must be confirmed in the current account documentation, quote, order form or service agreement that applies to the customer.
Confirm the authorized channel, remove secrets, classify the request and identify the account or commercial reference.
Keep one case thread, answer requests with traceable evidence and record any temporary workaround or change made during investigation.
Retest the same workflow, compare final delivery states, document the change and monitor unaffected routes for regression.
Use the authenticated support option shown in the account or the contact method named in the applicable commercial documents. This page does not invent a public mailbox or telephone number.
Provide destination countries, traffic purpose, sender type, volume and peak profile, launch date, reporting needs and any support, security or procurement requirements. Ask that route conditions and rates include an effective date.
Provide the account, message ID, UTC time, masked destination, country or network, sender, exact API result, final delivery state, business impact and recent changes. Never include an API key or active OTP.
No. Response targets, support hours, severity definitions and escalation rights are governed by the applicable written support or service terms.
Avoid publishing full numbers, message content or customer records. Use an authorized private channel and share the minimum masked evidence needed to investigate the issue.
Choose the correct path, include traceable evidence and remove credentials or unnecessary personal data.