Integrate Veltor
Call Veltor from your backend when someone claims a limited benefit. Completed evaluations return allow or deny. Work that cannot run because of billing returns skipped. Your application chooses what happens next.
1. Name the benefit
Create a benefit with a name you recognize and a stable key your backend will send. It can be a trial, credits, access, an offer, or something unique to your business. Names do not select different backend systems; every benefit uses the same architecture.
2. Configure Test
Review a preset or create a reusable policy in Test, then create a benefit and assign that policy with an enforcement mode. Create a RESTRICTED KEY with the permissions your backend needs, and keep it in your secret store.
3. Send a stable claim
Use the same claim ID for one logical request. Your backend supplies the signed-in user's email, any verification assertions, and, when available, the real client IP resolved from infrastructure you trust. An omitted IP does not block the evaluation. Reuse the idempotency key after a timeout or lost response.
curl https://veltor.dev/v1/evaluations \
-H "Authorization: Bearer $VELTOR_SECRET_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: attempt_customer_123" \
--data '{
"benefit": "signup_credits",
"claim_id": "signup_customer_123",
"subject": {
"external_id": "customer_123",
"email": "alex@example.com",
"email_verified": true
},
"context": {"ip": "192.0.2.10"}
}'4. Choose what the evaluation means
The successful response contains only an evaluation ID and allow or deny. One customer may create the account either way and add trial credits only after allow. Another may reject a duplicate trial signup after deny. Another may route deny into an internal review workflow. Veltor does not dictate or perform that consequence.
{"id":"evaluation-id","result":"allow"}Handle skipped work
Check status before reading an evaluation decision. A skipped result has no evaluation ID or allow/deny result. Handle it explicitly if you want signup to continue, and choose whether your application should provide the benefit without a Veltor evaluation. Do not send an outcome for skipped work. Reusing the same idempotency key returns the same terminal response; after billing is resolved, use a new key for new work.
{"status":"skipped","reason":"insufficient_credits"}5. Record what actually happened
If you use reported outcomes, send granted, not_granted, or reversed after your own workflow completes. Keep the delivery or business action idempotent in your database. A network timeout alone does not prove that your action failed.
6. Move to Live
Use Copy Test setup to Live to check for conflicts and copy benefits, current custom policies, registered identifiers, and unexpired exceptions in one operation. Review the Live setup, import known historical granted outcomes separately, and create a Live RESTRICTED KEY or SECRET KEY for your backend. Test history and credentials stay in Test.