1.2.0: out of beta.

Out of beta: shared webhooks, cleaner dialects, a clearer view of every number

The first release without the beta label. One webhook serves many accounts, a client's dialect answers from one list of fields, a vendor call maps each parameter on its own, and every number lookup is kept with the provider's own request and answer.

• One MO or DLR webhook serves many accounts: each account names the webhook it uses; HTTP Endpoints are now HTTP Webhooks, with a tester for any webhook
• Client dialects answer from one list of fields for accepted and refused messages, each field with fallbacks in order and sent always, on acceptance or on refusal; Try it shows the client's reply
• Vendor calls map values per parameter (the whole value or chosen variables) and map the vendor's answer back, with defaults for what it leaves out; XML inside a form value is escaped
• Number lookups keep the operator's name and country code, mark a number ported when its range belongs to another network, and are kept whether the message was accepted or refused
• HLR Logs show each provider call's request and answer; a number is read from our own data before any paid lookup, so a lookup is paid only for a new number or an expired answer
• Networks in the menu: MNP (the number data, its import, lookup order and providers, with how long each answer stays valid) and Operators
• Monitoring: MO, MT and DLR throughout, queues and clients waiting summed over every gateway, a full view of every role
• The Rejected log names the network each refused number was on

SQL Server end to end, every try kept

The admin side runs on SQL Server as well as MySQL, every attempt to hand a client an MO or a DLR is kept with its request and answer, and an HTTP vendor's calls are kept as they went.

• The Admin API and the portal run on SQL Server too, with the same test suite on both databases
• Every try to hand a client an MO or a DLR is kept, with the request and the answer; an HTTP vendor's calls are kept raw
• An MO webhook carries the subscriber's network, the vendor it came from and when the gateway took it in; MO and DLR webhooks need no account
• Long messages: a vendor's first receipt may close the message, and a client may get a receipt for each part
• MO and DLR rates are one bucket per gateway, with unused units handed back
• Monitoring watches SQL Server too; History has its own button, events and days
• Message logs ask for a company first; a conversion rate of 1 is a real rate
• The SMPP and encoding libraries are Go modules of their own; installs without trigger rights on MySQL are supported

Four database setups, one build

One Yakugate build now runs on MySQL + Redis, MySQL alone, SQL Server + Redis or SQL Server alone. Each database is reached through a data access layer of its own, and the same tests prove each one.

• SQL Server 2022 supported alongside MySQL; Redis optional on both
• A data access layer per database (MySQL, SQL Server, Redis): nothing outside it touches a database, and contract suites hold every layer to the same answers
• Without Redis, the SQL database also carries the queues, limits shared between processes in chunks, blocks, locks, dedupe and billing events
• smpp-server works on a set number of submits at once; the rest wait in the client's window (or are answered ESME_RTHROTTLED, by setting) instead of timing out
• Rate limits shared between processes no longer refuse under the cap
• Every refusal reaches the Rejected log, written in batches; written, dropped and failed counts on Monitoring
• The cause behind a refused balance step is logged with the store that failed
• Proved on all four setups: the full load mix with 0 failed checks and money matched to the last digit

First live release

The first release of Yakugate to carry live traffic.

• Dual-protocol edges: HTTP API v4 and SMPP 3.4, client-side and vendor-side
• 19-stage accept pipeline — validation, policy, credit, quota, HLR, routing, dedupe, durable enqueue
• Routing plans per account: a Main level and any number of backups, each choosing in order, cheapest, best delivery, best value or least busy, with retries in rounds
• Deployments: several gateways on one store, each account and vendor placed on the gateways that serve it, with throughput per gateway
• Config-driven vendor onboarding — REST/XML/SOAP adapters as JSON profiles with session-auth chains, hot-reloaded
• Vendor callbacks secured like customer submits: their own credentials, address lists, rates and lockouts, for receipts and incoming messages separately
• Concatenated (multipart) SMS with transport-correct delivery truth
• Full DLR lifecycle: all eight SMPP receipt states, correlation, client push over bind or webhook, retry, expiry, retention and archive
• Billing: buy/sell rating, prepaid ledgers, idempotent charging
• Abuse monitoring: sliding-window scoring with warn / throttle / suspend
• Per-account API dialects — legacy field names, response shapes and submit URLs preserved
• Security: JWT (HS256/RS256/ES256), bcrypt, lockout ladders, password-spray guard, anti-enumeration
• One command runs the whole gateway; a console sets it up with no portal
• Measured: 13,435 seg/s peak, p95 as low as 3.7 ms, 1.6M-message endurance at 100% acceptance

The internal generations

Three generations of gateway engineering inside commercial messaging operations — never published, but they are why the public API is already called v4. The lessons they taught (windowing, receipt parsing, throttle backoff, never-retransmit-on-timeout) are encoded throughout 1.0.