veltor
Developer documentation

Policies and benefits

Versioned policies evaluate supported facts deterministically. The first matching rule determines the candidate result.

Precedence and missing data

Blocked-list entries take precedence over trusted-list entries. Ordered rules follow, then the default result. ALL and ANY groups support two levels, up to 50 rules and 10 conditions per rule. Missing and unavailable facts do not satisfy ordinary comparisons; use explicit missing or unknown conditions.

Starting policies

Balanced denies prior canonical-email, supplied-payment, and verified-phone grants, plus confirmed disposable email with at least five IP attempts in one hour. Lenient uses canonical-email history only. Non-account benefit drafts also check their stable recipient ID. Strict adds confirmed-disposable denial and a device threshold of three prior recipients. Monitor evaluates rules while returning allow and recording actual grant history.

Eligibility periods

Once-ever history has no automatic reset. Separate benefit keys isolate campaigns. Calendar periods use day, ISO week beginning Monday, or month in an explicit timezone. Rolling eligibility uses 1–365 elapsed days. All recipient types require email and IP; workspace, company, and installation also require a stable external recipient ID.

Referral qualification

Your application reports that a referral qualified. The policy checks the referred recipient and self-referral evidence. One referrer can earn rewards for different eligible referred recipients. Each campaign has a separate benefit key.

Publication and replay

Saving a draft does not affect live decisions. Publication creates an immutable version. Restoring an earlier version creates another version. Historical replay applies proposed rules to retained facts without writing live claims or grants; it does not reconstruct earlier list membership.