Zayloft
Zayloft
REST APIs
Versioned JSON over HTTPS for messaging, verification, contacts, templates, webhooks, usage and account resources.
- Versioned resource paths
- Bearer authentication
- Idempotent write requests
- Structured error responses
Zayloft developer platform
Build customer communications and authentication into your products with clear APIs, predictable events and infrastructure designed for serious production workloads.
Use REST APIs for application workflows, SMPP 3.4 for suitable enterprise SMS connectivity, and signed webhooks to keep your systems synchronized with messaging, inbound activity and verification events.
A developer platform that fits into the systems you already run.
Use REST APIs for application-driven workflows, SMPP 3.4 where sustained SMS throughput and telecom-style connectivity are appropriate, and event-driven webhooks to keep your systems synchronized with delivery, inbound and verification activity.
SMPP 3.4
Enterprise SMS connectivity for workloads that benefit from persistent binds, telecom-oriented throughput controls and delivery receipt handling.
- Transceiver, transmitter and receiver binds
- submit_sm and deliver_sm workflows
- Delivery receipts and message states
- Throughput and connection controls
Webhooks & events
Receive asynchronous lifecycle events for delivery, inbound communication, verification, account and workflow activity.
- Signed event payloads
- Delivery and inbound events
- Retry-safe processing
- Event IDs for deduplication
Authentication & credentials
Use environment-scoped credentials and least-privilege access patterns so applications receive only the capabilities they need.
- Scoped API credentials
- Test and live separation
- Key rotation patterns
- Server-side secret handling
Design requests that are safe to retry.
Network failures and timeouts are normal parts of distributed systems. Zayloft integration patterns use idempotency, stable request identifiers and explicit event states so applications can recover without blindly duplicating customer actions.
Idempotency
Attach a unique key to eligible write requests so retries can be recognized instead of creating unintended duplicate operations.
Correlation
Use stable application and request identifiers to trace work across your system, Zayloft and downstream delivery events.
Timeout handling
Treat transport timeouts as unknown outcomes until the request state can be safely resolved.
Event reconciliation
Reconcile asynchronous delivery and inbound events against your own records using durable identifiers.
A clean API surface for application teams.
The examples below use an environment variable for the API base URL so your deployment can point to the hostname and version configured for your account.
Example request
curl "$ZAYLOFT_API_BASE/v1/messages" \
-H "Authorization: Bearer $ZAYLOFT_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: 8f36c1f0-8e7d-4d9d-a342-7aef0c2d45c2" \
-d '{
"channel": "sms",
"to": "+14155550123",
"message": "Your verification code is 482731"
}'Keep credentials on the server. Never embed API secrets in browser JavaScript, public repositories or mobile application bundles.
Clear events. Better debugging.
Applications should not have to infer message state from a single synchronous response. Delivery, inbound and verification events provide the state changes needed to reconcile customer workflows.
Accepted
The platform has accepted a valid request for processing.
Sent
The message has progressed through the configured delivery path.
Delivered
A downstream delivery confirmation has been received where the channel provides one.
Failed
The operation could not complete and exposes a structured reason suitable for application handling.
Inbound
A customer-originated message or channel event is available to your application.
Verified
A verification workflow has completed successfully according to the configured method.
Developer resources for evaluation, integration and operations.
Start with the integration surface you need, then move into contracts, environments, logs, webhook inspection and usage visibility as your implementation grows.
OpenAPI contracts
Machine-readable API definitions support documentation, validation and SDK generation workflows.
Test environments
Keep development and production credentials, data and application behavior separated.
Request logs
Trace request IDs, response states and important metadata without exposing secret provider internals to ordinary users.
Webhook inspection
Inspect delivery attempts, event IDs, signatures and retry history when diagnosing integration behavior.
Usage visibility
Track API activity, messaging volume and account consumption using organization and project boundaries.
Status awareness
Use service-health information and application-side resilience patterns to reduce avoidable disruption.
Security belongs in the integration design.
Zayloft developer integrations should keep secrets server-side, verify webhook authenticity, isolate tenants and environments, limit credential scope and record important administrative actions.
Secret isolation
Store API keys, SMPP credentials and webhook secrets in protected server-side configuration.
Webhook verification
Validate signed payloads before trusting event content or triggering downstream actions.
Least privilege
Issue credentials with only the scopes, projects and environments required by the application.
Tenant boundaries
Keep organization and project data isolated throughout request handling and resource access.
Auditability
Record key administrative and credential events for operational accountability.
Transport protection
Use modern TLS for public API transport and secure channels for supported persistent protocol connections.
Frequently asked questions
REST is usually the simplest choice for application-driven messaging and product workflows. SMPP is appropriate for certain enterprise or telecom-oriented SMS workloads that benefit from persistent sessions and throughput controls.
Keep them in protected server-side secret storage or environment configuration. Do not place them in browser code, public repositories, logs or client applications that cannot protect secrets.
A client may not know whether a timed-out request succeeded. Idempotency lets eligible retries be recognized so the application can recover without creating unintended duplicate work.
Process events idempotently, persist event identifiers and acknowledge successful handling quickly. Your application should tolerate duplicate delivery attempts.
Yes. Organization, project and environment boundaries are the appropriate way to isolate applications, teams and operational access.
Where the selected channel, sender resource and destination support inbound traffic, events can be delivered to the application through configured webhook workflows.
No. A synchronous success generally means the request was accepted for processing. Final delivery state should be determined from the channel’s delivery events or receipts where available.
Yes. REST APIs, webhooks, SMPP for suitable SMS workloads and approved data interfaces are intended to fit into existing application and operational architectures.
Build communication infrastructure your application can reason about.
Use predictable requests, scoped credentials, asynchronous events and operational visibility to connect Zayloft with the systems your engineering teams already run.
For API, SMPP, webhook or technical integration enquiries, contact support@zayloft.com.