Developer Access

SMSBite provides a message submission API to verified business customers. Documentation and credentials are issued, not self-served: no form on this website produces a working API key.

Access runs in a fixed sequence:

• Business enquiry — you contact us and describe the entity, the intended traffic and the destination countries.
• Commercial conversation — requirements, destinations, expected volumes and indicative per-destination rates are discussed.
• KYB/KYC review — verification of corporate registration, beneficial ownership and signatory identity, with sanctions screening and a review of the declared use case and sender identity.
• Order Form — commercial terms, contracted submission rate, destinations and rates fixed in a signed Order Form, issued with the Data Processing Addendum.
• Sandbox credentials and documentation pack — issued to your named technical contact.
• Integration — you build and test against the sandbox with a named integration contact on our side.
• Production enablement — production credentials issued and traffic enabled, initially within agreed volume limits.

There is no route to production traffic that bypasses this sequence, and it applies to every account without exception. It is the same onboarding process set out on the contact and legal entity page.

The API reference, the integration guide and sandbox access are issued directly to verified business customers, and to prospects under a mutual non-disclosure agreement, alongside the Order Form.

Gating the integration surface is a deliberate abuse-prevention control. Publicly documented submission endpoints attract automated credential probing and are a standard starting point for parties with no intention of passing KYB; keeping the surface visible only to counterparties we have identified and contracted with removes that entire class of attempt. It also keeps routing, rates and contracted throughput where they belong — in the Order Form, specific to your account.

Ask for the technical material during the commercial conversation and it is released under NDA, typically within two business days of the NDA being signed.

The documentation pack issued on access contains:

• API reference — the complete specification of the message submission interface and its authentication model.
• Integration guide — the recommended sequence for building, instrumenting and hardening an integration.
• Sample code — worked examples in commonly used server-side languages.
• Delivery-receipt and webhook specification — how delivery telemetry passed back from the operator reaches your receiver, and how it is retrieved by polling where no receiver is used.
• Sandbox credentials — per-account API keys for the non-production environment.
• Test destinations — sandbox destinations exercising the range of delivery outcomes without reaching an operator.
• Named integration contact — a person at SMSBite responsible for your integration through to production enablement.
• Order Form, DPA and SLA — the commercial terms, the data-processing terms and the Service Level Agreement, which together govern the account.

Most of the following is required for KYB and use-case review in any event, and gaps here are the usual cause of delay between enquiry and production.

• Legal entity and KYB documents — certificate of incorporation, evidence of beneficial ownership, signatory identification and the registered trading address.
• Declared traffic type per destination — transactional, authentication or marketing, stated separately for each destination country, with representative message content.
• Sender IDs— the identifiers you intend to use, their registration status in each destination country that operates a registration or pre-clearance regime, and evidence of your right to use them.
• Expected monthly volume and peak submission rate — the steady-state figure and the peak you expect to reach. The contracted submission rate is set from these.
• Webhook receiver — a receiver you operate, reachable from the public internet over TLS with a publicly trusted certificate, able to accept delivery telemetry continuously and absorb bursts without dropping them.
• Source IP ranges — the addresses your application submits from, so they can be recorded and allow-listed against your account credentials.
• Opt-in evidence and opt-out process — how consent is captured, stored and retained, and the process by which an opt-out is honoured and propagated to your sending systems. The retention and production requirements are set out in the Anti-Spam & Messaging Compliance Policy.
• Named contacts — a technical contact for the integration and an abuse escalation contact who can be reached out of hours and can stop traffic.

These are obligations rather than interface detail. They are restated in the documentation pack and are conditions of production enablement.

• Treat resubmission as idempotent — the platform supports idempotent resubmission so that a retry after an ambiguous outcome does not duplicate a message. Use it, and never retry blindly.
• Consume delivery receipts asynchronously — acceptance of a submission means the message has been queued for onward routing; it is not delivery. Final status arrives later, out of band, and in some destinations never arrives in a meaningful form, as described in the SLA.
• Stay within the agreed submission rate — pace your sending to the contracted rate recorded in your Order Form. Sustained excess may be throttled or treated as a customer-caused issue under the SLA.
• Keep API keys server-side — keys are issued per account and must never be embedded in a mobile or browser application, or any other client the end-user controls, and never committed to a source repository.
• Rotate and revoke — rotate keys when personnel with access to them change, and revoke immediately on suspected compromise. Report a suspected compromise to security@smsbite.com.
• Log your own request identifiers — retain your correlation identifiers alongside the identifiers we return, with timestamps in UTC, so an incident on your side can be matched against our records.

The measures SMSBite implements on its own side are on the security page. The traffic that may be sent is governed by the Acceptable Use Policy.

Sandbox credentials let you build and test an integration — authentication, submission handling, error handling and delivery-telemetry consumption — without operator delivery and without charges. Sandbox usage is not invoiced.

Sandbox behaviour is representative but not identical to production. Delivery telemetry is generated by SMSBite rather than by an operator, and the sandbox does not reproduce operator-side filtering, sender-ID rewriting, portability behaviour, route congestion or destination latency. Sandbox results are not a prediction of production delivery outcomes.

The sandbox is excluded from the availability target and service credits under the SLA.

Production credentials are issued after a review with your integration contact, which checks:

• Sender IDs registered and approved in every destination country that requires registration, and substantiated as belonging to you.
• Opt-out handling demonstrated end to end, including how it reaches your sending systems and how quickly it takes effect.
• Traffic type matching the declaration made at onboarding, per destination, including the content categories reviewed.
• The contracted submission rate recorded in the Order Form, with upstream capacity arranged against it.
• Technical and abuse escalation contacts recorded and reachable.

Production traffic is enabled initially within agreed volume limits and is monitored against the declared use case. Traffic that differs materially from that declaration — a different content category, an unregistered sender identity, or destinations outside the agreed set — may be throttled or suspended under the Acceptable Use Policy. If your use case changes, tell us before the traffic does.

Integration questions and incident reports go to sales@smsbite.com. The severity model, the target initial response window for each severity, the staffed support hours and the on-call arrangement for critical incidents are set out in the Service Level Agreement and are not restated here.

A report should identify the affected account, timestamps in UTC, the request identifiers you logged, the destination countries and the responses you observed. Incomplete reports may be triaged at a lower severity.

Abuse reports concerning traffic sent through SMSBite go to abuse@smsbite.com. Vulnerability reports and suspected credential compromise go to security@smsbite.com. Routing either through general support delays it.

Planned maintenance and incidents are published on the Service Notices page and notified to account contacts by email in accordance with the SLA.

This page describes the access process. The obligations themselves live in the documents below.

• Terms of Service — the master agreement.
• Service Level Agreement — availability target, exclusions, support severities and service credits.
• Security — the measures implemented on the SMSBite side.
• Acceptable Use Policy — what may and may not be sent through the platform.
• Anti-Spam & Messaging Compliance Policy — consent, opt-in evidence, opt-out and destination-country registries.
• Contact & legal entity — the onboarding sequence and contact directory.

To begin, write to sales@smsbite.com with the legal entity, the destination countries, the traffic type and the expected monthly volume.