Security for customer messaging infrastructure.
A technical overview of how SendiMessage protects accounts, API access, messaging data, managed lines, and webhook integrations. Everything on this page is verified against the implementation — where something isn't built yet, we say so.
What is actually implemented.
Six controls, stated specifically. Each one is verified in the codebase and exercised by the product every day — no vague “enterprise-grade” adjectives.
API authentication
Every API request authenticates with two headers — a key and a secret. Secrets are stored only as one-way hashes and compared in constant time; a missing or revoked credential is rejected before any resource is touched.
Tenant isolation
Every resource belongs to exactly one organization, and every query is scoped by the organization resolved from the authenticated credential — enforced server-side and covered by automated cross-tenant tests.
Signed webhooks
Deliveries to endpoints with a signing secret configured carry an HMAC-SHA256 signature of the raw request body, so your application can verify the event came from SendiMessage and reject tampering.
Encrypted transport
Web and API traffic is served over HTTPS/TLS, with baseline security headers: HSTS, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy, and Permissions-Policy.
Access control
Customer roles (owner, admin, developer, member) gate portal areas server-side — credential management is owner-only. Internal staff surfaces use a separate staff-role system customer accounts cannot reach.
Managed infrastructure
Messaging lines are provisioned, configured, rate-limited, and health-monitored by SendiMessage. Your application only ever talks to the REST API — the line infrastructure is never exposed to you or anyone else.
Your organization is isolated from other customers.
Every SendiMessage resource is associated with a customer organization, and authorization is enforced server-side on every request: the organization is resolved from the authenticated credential, and queries are scoped to it. An authenticated customer cannot read, list, or act on resources belonging to another organization.
organization_a
Every resource belongs here — and only here- Users
- API credentials
- Lines
- Messages
- Conversations
- Contacts
- Webhooks
organization_b
Every resource belongs here — and only here- Users
- API credentials
- Lines
- Messages
- Conversations
- Contacts
- Webhooks
Public identifiers are opaque handles (message_handle, line_handle, contact_handle, conversation_handle) — numeric database IDs are never exposed, so identifiers can't be guessed or enumerated. These behaviors are covered by an automated cross-tenant test suite that runs against the real API surface.
API credentials stay under your control.
Credentials are issued once, stored as one-way hashes, revocable at any time, and always visible in terms of when they were last used.
Verify every webhook.
Deliveries are signed with an HMAC-SHA256 of "{timestamp}.{raw request body}" (lowercase hex), keyed with your webhook secret, so your application can prove an event came from SendiMessage before trusting it.
How customer data moves through SendiMessage.
Both directions of a conversation, with the security property active at each hop.
Outbound — you send a message
Inbound — your customer replies
Data handled by SendiMessage.
What we store to run the product — no more categories, and no hidden ones.
Account
- Organization details
- User accounts & work email
- Roles & membership
Messaging
- Message content & direction
- Sender / recipient numbers
- Status & timestamps
- Contacts (name, company, tags, custom variables)
- Conversations
- Per-org opt-out state
Integration
- Webhook endpoints & delivery records
- API credential metadata (never raw secrets)
- Line configuration
Operations
- Audit log of security-relevant actions
- Request correlation IDs
- Support conversations
Retention
Message and conversation history is retained to power the product's history, conversation, and delivery-tracking features. We have not yet published formal retention windows — a formal retention policy is being defined, and we say so rather than inventing numbers. If your review needs specifics for a category, ask us and we'll give you the current factual answer.
Deletion — what you can do today
Encryption — precisely stated
Access is permission-controlled.
Customer roles gate what each person in your organization can do — enforced server-side on every portal request, not hidden in the UI.
Internal staff surfaces are gated by a separate staff-role system with per-area permissions. Customer accounts cannot reach staff tooling, and administrative access to production systems is restricted to authorized personnel. Security-relevant staff actions — provisioning, credential delivery, admin changes — are recorded in the audit log.
Infrastructure and operations.
The operational controls behind the product — described at the level that's useful to you, without publishing internal topology.
Subprocessors.
Third-party services verified in the current implementation. Messaging data stays on SendiMessage-managed infrastructure.
Customer messages are transported and stored on SendiMessage-managed infrastructure — message content is not sent to the analytics vendors above. A complete, current service-provider list for your data-processing review is provided as part of vendor security review — contact us.
Compliance and certifications.
SendiMessage does not currently hold SOC 2 or ISO 27001 certification, and we will never imply otherwise with badges or “coming soon” seals. What we publish instead is the specific, verifiable behavior above — and a straight answer when something isn't built yet.
Report a security issue.
Found something? We want to know, and we'll take it seriously.
- Email a description of the issue, the affected endpoint or page, and reproduction steps.
- Please do not access data that is not yours, alter or destroy data, or degrade the service while testing.
- We investigate every credible report and will keep you informed of the outcome.
- We do not currently run a paid bug-bounty program, and we won't pretend to.
The questions a reviewer actually asks.
How does API authentication work?
Every request must carry both X-API-Key and X-API-Secret headers — bearer tokens are not the authentication method for this surface. Secrets are stored as one-way hashes and verified with constant-time comparison. Requests without valid credentials receive 401 Unauthenticated.
Can another customer access our lines or messages?
No. Every query is scoped to the organization resolved from the authenticated credential, server-side. Reading another organization's resource returns 404 Not found, and sending through a line that isn't yours is rejected with no message created. This behavior is covered by an automated cross-tenant test suite.
How do we verify webhooks are really from SendiMessage?
Each delivery carries an SendiMessage-Signature header: the hex HMAC-SHA256 of the raw request body, computed with your webhook secret. Recompute it over the exact bytes received and compare in constant time — verification examples are in the API docs.
Is our data encrypted?
In transit, yes — HTTPS/TLS with HSTS. At the application level, API secrets are stored as one-way hashes. We deliberately do not make a blanket “everything encrypted at rest” claim; ask us during review for the current storage configuration.
What customer data do you store?
Organization and user account data, message content with sender/recipient numbers and delivery status, contacts and conversations, webhook configuration and delivery records, API credential metadata (never raw secrets), and audit logs. The full breakdown is in the Data section above.
How long do you retain data, and can it be deleted?
Formal retention windows are not yet published — we're defining a retention policy and say so instead of inventing numbers. You can revoke credentials and delete webhooks and contacts yourself today; organization deletion is handled with our team on request.
Do you have SOC 2, MFA, or SSO?
Not yet, and we say so plainly: no SOC 2 or ISO 27001 certification, no customer-facing MFA (on the roadmap), no SSO/SAML. If your review requires any of these, tell us — real demand moves the roadmap.
How do we report a security issue?
Email hello@sendimessage.com or use the security contact form. A machine-readable /.well-known/security.txt is published. Please avoid accessing data that isn't yours and avoid destructive testing.