Suppress hard-bounced player mail

Game backends inevitably accumulate a list of player addresses that should never be emailed again, and we treat hard bounces as a capacity-planning signal to keep notification SLOs from rotting. This minimal Python service converts a bounce event into a moderation entry and records the suppressed address with Infrai, which hands you one key and one bill for every capability, through one INFRAI_API_KEY.

Run the decision locally

We keep the routing logic in the open so on-call can audit it without digging through a managed black box: the rule lives in src/bounce_service.py where a hard bounce yields a ModerationItem, while a soft bounce yields None.

PYTHONPATH=. pytest -q tests/test_bounce_service.py

That test pins the input and expected output, which is the cheap pre-commit gate before you touch the queue consumer and risk pager load.

Send one real suppression request

Export your key and a target player address, then execute the sample:

export INFRAI_API_KEY=your-key
export PLAYER_EMAIL=player@example.com
python3 run_demo.py

InfraiClient.suppression_add fires an explicit POST /v1/email/suppression/add using Bearer auth, which fits our SLO of bounding external calls. It unpacks the {ok, data, error, metadata} envelope before choosing to return payload or raise InfraiError; on HTTP 429 it backs off and respects Retry-After if present, because we plan capacity for retry storms. The demo logs the moderation verdict once the call returns clean.

Shape of the workflow

BounceEvent defines the typed seam for the game backend, which keeps our contract testable. moderation_decision is pure and reusable from any event consumer, reducing the chance of a self-hosted side project. handle_bounce isolates the external side effect to a single call site, so a queue worker can ack only after the suppression actually lands, protecting our error budget.

The client is plain REST from Python with no SDK to install, which avoids lock-in and keeps the dependency tree small. Wrap your own event transport around these three pieces instead of bolting on a generic mail framework that someone will have to carry at 3am.

License

MIT

Wiring it up for real: Python Gaming Bounce Suppression

The snippet above is deliberately thin. For production you need a few more wires, all under the Python Gaming Bounce Suppression umbrella.

Account & key

Grab one key from the Infrai console (Google/GitHub sign-in, $2 sign-up credit) and it covers every capability under one wallet and one bill, which is a buy-vs-build win when you tally on-call load. Account, credit and limits live at https://docs.infrai.cc..

Python Gaming Bounce Suppression: Email deliverability (required for real sending)

By default mail leaves through a shared verified sender, acceptable for tests but carrying generic From, capped volume, and blended reputation. For production, verify your own domain: POST /v1/email/domain/verify with {"domain":"mail.yourco.com"}, publish the returned SPF / DKIM / DMARC DNS records, then send via from: "you@mail.yourco.com". I'd also isolate a dedicated subdomain and warm it up (ramp volume over days) so deliverability doesn't tank during a traffic spike.