API integration
Authentication, request construction, response parsing, idempotency, timeouts, retries, webhook handling and production migration.
TextPulse support center
SMS support for integrations, delivery, accounts and billing
Start with the part of your messaging workflow that is blocked. A useful support request identifies the account, destination, sender, request time, message ID and observed result without exposing API keys, one-time codes or unnecessary message content.
Support scope
Choose the path that matches the problem
Separating configuration, delivery, commercial and account questions reduces unnecessary handoffs and makes the first investigation more useful.
Delivery investigation
Accepted requests, pending states, final delivery reports, carrier rejections, invalid destinations, latency and route-specific behavior.
Sender setup
Sender type, registration status, approved templates, destination restrictions and launch readiness for a country or traffic class.
Account access
Login recovery, team access, API-key rotation, project separation and questions about account-level configuration.
Billing and quotes
Route quotes, currencies, balance questions, message segments, billable events, invoice references and commercial document clarification.
Security and abuse
Suspected credential exposure, unusual traffic, account misuse, OTP abuse and information needed to contain an incident safely.
Fast triage
Trace the message from request to final outcome
An HTTP success only confirms what that response explicitly says. It does not automatically prove handset delivery. Follow the lifecycle in order so the investigation starts at the first missing or unexpected state.
Validate the request
Confirm the endpoint, authentication method, recipient in E.164 format, sender, encoding, template and account environment. Remove secrets before sharing logs.
Record the API result
Keep the HTTP status, provider status, request or message ID and UTC time. Distinguish a transport error from a rejected request or an accepted submission.
Follow status changes
Correlate webhooks or delivery reports by message ID. Check whether the state is pending, final, expired, rejected, undeliverable or mapped from a carrier-specific result.
Compare the route context
Group failures by destination, network, sender, template, time window and traffic type. A concentrated pattern is more actionable than one isolated screenshot.
Case quality
Send enough evidence without sending secrets
| Include | Why it helps | Do not include |
|---|---|---|
| Message or request ID | Correlates API acceptance, routing events and delivery reports. | Secret API keys, passwords or full authorization headers. |
| UTC timestamp and time window | Narrows the relevant logs and separates current behavior from an older event. | Only a local time without a timezone. |
| Destination country, network and masked number | Identifies route and carrier context while reducing unnecessary exposure. | Large lists of full recipient numbers. |
| Sender type, template and encoding | Reveals registration, content, segmentation or compatibility issues. | OTP values, passwords or sensitive message content. |
| Sanitized request and exact response | Shows fields, status mapping and whether the request reached the service. | Unredacted tokens, cookies or private customer records. |
| Expected behavior and impact | Separates a product question from an incident and explains urgency. | Claims of universal failure without a measured sample. |
Impact classification
Describe severity with observable facts
Your applicable support agreement controls any formal priority, response target or escalation entitlement. These descriptions help communicate impact; they do not create an SLA.
Production unavailable
A live, time-sensitive workflow cannot operate for a material share of traffic and no reasonable workaround is available. Include start time, affected countries, failure rate and recent changes.
Production degraded
Messages continue but latency, failure rate, status reporting or a subset of destinations behaves materially outside the observed baseline.
Configuration blocked
A launch, sender registration, webhook configuration or account change cannot proceed, but an existing production workflow remains available.
Question or request
Documentation, pricing, invoice, product behavior or planned implementation needs clarification and there is no active production impact.
Security handling
Contain credential or traffic abuse before normal troubleshooting
If a credential may be exposed
- Rotate or revoke the affected key through the authorized account workflow
- Restrict source systems and permissions where available
- Preserve sanitized timestamps and request identifiers
- Review unusual destinations, volume and balance changes
- Contact the authenticated support channel with the containment status
If OTP traffic is being abused
- Apply per-user, per-number, per-IP and per-device rate limits
- Use resend cooldowns and attempt limits
- Block repeated destination or network anomalies
- Measure verification completion, not only message submissions
- Keep codes and personal data out of support attachments
Launch readiness
Test the support evidence before production
A production launch should not be the first time the team tries to trace a message. Run a controlled test that exercises the same sender, destination class, template, callbacks and application behavior planned for live traffic, then save the evidence needed to diagnose a later change.
Define success
Record the expected API result, delivery states, latency window and user outcome for representative destinations. A baseline must be specific enough to show when behavior has materially changed.
Exercise failure paths
Test invalid numbers, duplicate requests, timeouts, delayed callbacks and rejected messages in a safe environment. Confirm that retries do not create duplicate sends and that final failures reach the right operational queue.
Verify observability
Make sure message IDs connect application logs, API responses, webhook events and user actions without storing active OTP values or excessive personal data. Confirm clocks use a consistent timezone.
Keep a change record
Document sender approvals, route or account changes, application releases, template revisions and traffic shifts. When an issue starts, this timeline often identifies the first useful comparison.
After any fix: Retest the same controlled sample, compare the complete message lifecycle, watch for regression in unaffected destinations and record what changed. Closing a case on one successful submission can hide a continuing delivery or callback problem.
Self-service resources
Check the guide closest to your workflow
Support questions
Where do I open an account-specific support request?
Use the authenticated support option displayed in your account or the contact method stated in your applicable commercial documents. This public page intentionally does not invent an email address or service commitment.
Why is an accepted message not yet delivered?
Acceptance and handset delivery are different states. Follow the message ID through delivery reports, confirm whether the result is pending or final, and compare the destination, carrier, sender and template context.
What should I provide for a delivery investigation?
Provide a message ID, UTC timestamp, masked destination, country or carrier, sender, template or encoding, exact final status and a sanitized request and response. A small representative sample is usually more useful than a screenshot alone.
Can support guarantee a sender, route or delivery rate?
Availability and behavior can vary by destination, carrier, sender type, registration, content and effective date. Confirm the current account-specific route terms and test the real workflow before production.
Should I send an API key or OTP to support?
No. Do not send secret keys, passwords, authorization headers, active OTP values or unnecessary personal data. Redact sensitive fields and rotate a key immediately if exposure is suspected.
Start with a traceable message lifecycle
Document the request, message ID, delivery state and route context before escalating. That evidence makes integration and delivery support more precise.