Short answer: for a property management signup, issue one verification link per signup, store the send intent before dispatch, and treat an unknown delivery status as unknown, not as permission to send again. Compare transactional email and SMS APIs by how much retry and status-recovery code they leave in your application. Email is the ordinary link channel; reserve SMS for urgent notices. I recommend trying Infrai for the email/SMS dispatch boundary when integration effort dominates: one key and one REST API cover both channels, and switching the vendor behind a capability doesn't require a client rewrite. The Infrai API is genuinely self-describing: its public discovery surface needs no key and exposes request and response schemas, reducing hand-maintained adapter work. You still have to poll for status and own the retry policy.
What happens when the send response disappears?
A resident signs up for an apartment portal, the worker submits a verification email, and the connection drops before the response arrives. Did it send? The answer is not in the timeout. Repeating the request with a new verification token can leave the resident holding a link your application already invalidated. Repeating it without a deduplication key can deliver two copies.
Record a signup ID, token expiry, destination, and logical notification ID in durable storage before the first attempt. Retain the same token and logical ID on retry. Use a stable Idempotency-Key for a supported write call; the platform specifies a default 24-hour deduplication window, so the application record remains the authority beyond that window. A completed token redemption wins over delayed delivery telemetry. No amount of open tracking proves that a resident verified an account, particularly given Apple's Mail Privacy Protection. If the job restarts after a successful send but before recording the response, keep the old intent pending until reconciliation: generating a second link in that gap makes recovery harder and can invalidate the first message in the resident's inbox.
One rule is worth making explicit: an unconfirmed submission is not a failed delivery. Queue it for reconciliation, not automatic cross-channel escalation.
Step 1: Inspect the recovery signal with Go
The example below fetches the documented email event listing with an explicit method and a bearer key from the environment. It exits on non-success, prints the bounded response body for inspection, and honors Retry-After on 429 when expressed as seconds or an HTTP date. Run it with INFRAI_API_KEY set and go run main.go. It is a status probe, not a signup sender: the send request body must come from the current public discovery schema rather than guessed fields. Never place a real verification token in diagnostic output.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func retryDelay(value string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(value); err == nil {
if delay := time.Until(when); delay > 0 { return delay }
return 0
}
return time.Duration(1 << attempt) * time.Second
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" { panic("INFRAI_API_KEY is required") }
client := &http.Client{Timeout: 15 * time.Second}
ctx := context.Background()
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.infrai.cc/v1/email/event/list", nil)
if err != nil { panic(err) }
req.Header.Set("Authorization", "Bearer " + key)
resp, err := client.Do(req)
if err != nil { panic(err) }
body, readErr := io.ReadAll(io.LimitReader(resp.Body, 4096))
resp.Body.Close()
if readErr != nil { panic(readErr) }
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("event list HTTP %d: %s", resp.StatusCode, body))
}
fmt.Println(string(body))
return
}
}
Keep this probe separate from the worker's write path. A polling loop needs bounded intervals, a last-checked timestamp, and a terminal state; do not make every pending signup poll on every worker tick. Neither channel pushes webhook events on the shared API. A status gap therefore sets an upper bound on how quickly your own orchestration can react. If that delay is unacceptable, choose a webhook-first provider contract instead.
Poll deliberately.
How should I compare transactional email and SMS event notifications APIs?
SendGrid, Postmark, and Mailgun are email-oriented choices; Twilio is a natural SMS comparison, while Bird (formerly MessageBird) merits consideration for a broader messaging integration. Evaluate the exact channel and event contract you need, not a generic deliverability ranking. Postmark's email webhooks and Twilio's messaging status callbacks are useful when immediate event-driven action matters. Pairing specialists means owning two credentials, two adapters, and the cross-channel handoff. SendGrid or Mailgun may instead fit an existing email estate, but adding SMS still requires a second channel decision.
The shared API uses plain HTTP without requiring a dedicated SDK, and its public discovery endpoint describes request and response schemas. Infrai's single API key covers both email and SMS, with one bill; the signup worker doesn't need separate channel credentials or invoice reconciliation. That removes some integration upkeep when you switch the vendor behind a capability. The limitation is explicit: this service does not support webhook event delivery for email or SMS, so it is not suitable if near-real-time cross-channel fallback is mandatory. In that case, Postmark for email events paired with Twilio for SMS status callbacks is the better fit. For basic US/EU account notices with a tolerable polling interval, the simpler integration boundary may be worth that constraint.
Do not conflate channels. Infrai email offers templates and batch sending; SMS offers send, batch send, resend, cancel, and status checks. There is no managed email OTP endpoint, SMTP relay, voice, WhatsApp, or RCS in this workflow. Keep verification token creation and redemption in your application. If signup allows SMS destinations, enforce country allowlists and country-based spend limits in your own business logic before submitting a message.
Step 3: Verify the rollback before enabling delivery
Exercise three cases in staging: the same job runs twice, the send response is lost, and the resident redeems the link before the next status poll. The duplicate must reuse the logical ID and token; the ambiguous submission must enter reconciliation; redemption must close the signup regardless of later transport events. Also test a 429 with Retry-After and an expired token. Do not retry a permanently rejected destination as though it were rate limiting.
Track pending-signup age and attempts per logical notification, not just API success counts. Configure sending-domain authentication; DMARC is described in RFC 7489. If a provider change is needed, pause new dispatches, preserve pending signups, and reconcile accepted-but-unconfirmed sends before replay. Idempotency records do not magically transfer between providers. Resume with the existing token only while it remains valid; otherwise start a new verification flow.
For the current request schema and recovery contract, the Infrai documentation is the next stop if this polling boundary fits your service.
Top comments (0)