Policy Simulation
Dry-run sends against the policy engine without actually sending email.
Policy simulation lets you test whether a send would be allowed or blocked — without actually sending the email. Use it to pre-check sends, validate batch campaigns, and inspect remaining quotas.
Simulate a single send
POST https://api.molted.email/v1/agent/simulate-sendcurl -X POST https://api.molted.email/v1/agent/simulate-send \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"tenantId": "tenant_abc123",
"recipientEmail": "user@example.com",
"templateId": "campaign-march",
"dedupeKey": "march-user@example.com"
}'Response
{
"wouldAllow": true,
"simulation": true
}{
"wouldAllow": false,
"reason": "cooldown",
"cooldownExpiresAt": "2026-03-01T12:10:00Z",
"simulation": true
}{
"wouldAllow": false,
"reason": "suppressed",
"suppressionInfo": {
"scope": "tenant",
"reasonCode": "hard_bounce"
},
"simulation": true
}The response uses the same reason values as real sends — see Errors & Policy Blocks for the full list.
Simulate a batch
Dry-run policy evaluation for up to 500 recipients.
POST https://api.molted.email/v1/agent/simulate-batchcurl -X POST https://api.molted.email/v1/agent/simulate-batch \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"tenantId": "tenant_abc123",
"requests": [
{ "recipientEmail": "user1@example.com", "templateId": "campaign-march", "dedupeKey": "march-user1" },
{ "recipientEmail": "user2@example.com", "templateId": "campaign-march", "dedupeKey": "march-user2" }
]
}'Check remaining quotas
GET https://api.molted.email/v1/agent/budgetcurl "https://api.molted.email/v1/agent/budget?tenantId=tenant_abc123" \
-H "Authorization: Bearer YOUR_API_KEY"Response
{
"monthly": { "used": 450, "limit": 1000, "remaining": 550 },
"daily": { "used": 23, "limit": 10000, "remaining": 9977 },
"hourly": { "used": 5, "limit": 1000, "remaining": 995 }
}Important notes
- No side effects — simulations do not increment counters, create send records, or trigger delivery. They are read-only.
- Time-of-check vs. time-of-use — a simulation result reflects the policy state at the moment of the check. By the time you submit the actual send, conditions may have changed (e.g., another agent may have consumed budget). Treat simulation results as guidance, not a guarantee.