Policy & outbound
How policy-gated outbound works — evaluate first, authorize, then place. Blocked categories and the broker example.
Live outbound calls and SMS never leave the machine unchecked. OpenPhonex makes the agent evaluate policy first, surface the decision and cost, and only then authorize and place. Scopes fail closed, and the policy engine blocks whole categories of outbound regardless of scope.
Your workspace capabilities
Every workspace has one capabilities record from the moment it is created.
It says what the workspace may do outbound: the use-case profiles, the channels
(voice, SMS), the destinations, the caps, and — for a customer application —
the calling rules. authorize_outbound checks it on every attempt, and a
workspace whose record is not active cannot place an outbound call or SMS.
Read and manage it on the Capabilities page in the workspace, or
programmatically: GET /v1/organizations/{organization_id}/capabilities
(onboarding:read) and POST /v1/organizations/{organization_id}/capabilities
(onboarding:write), or the get_capabilities / request_capabilities MCP
tools.
Activation is automatic
There are two doors, and both activate the record the same way:
- an OpenPhonex operator approves your business verification, or
- your first phone number needs no carrier registration, so the workspace is trusted for outbound as soon as it is ordered.
Activation grants the default profile (business support & callbacks) with its catalog caps, the channels your workspace can use (voice; SMS unless every number you hold is voice-only), and every destination except sanctioned countries. Sanctioned destinations are blocked for every workspace in every state. Operators can tighten from there; you request more below.
| Status | Meaning |
|---|---|
| Not activated | The workspace has not cleared verification yet. Outbound is refused. |
| Pending review | A request needs an OpenPhonex operator (a standard profile requested before verification finished, or the custom implementation-services profile). Nothing new is authorized yet; what was active stays active. |
| Active | Outbound calls and SMS are authorized within the profiles, channels, destinations and caps on the record. |
| Suspended | An operator paused outbound for this workspace. |
Destination controls
The Capabilities page shows your workspace's available destinations first. Ordinary business and personal calls do not require a separate use-case application. Workspace limits, acceptable-use rules, recipient permissions, number-specific requirements and carrier availability still apply.
Use Restrict destinations to open Optional destination restrictions and narrow the destinations your workspace can call or text. Choose all currently available destinations, or search and select specific countries. This setting is separate from your workspace's authorization: removing your restriction cannot undo an operator restriction or activate a suspended workspace.
For API clients, read destination_revision from
GET /v1/organizations/{organization_id}/capabilities, then send
POST /v1/organizations/{organization_id}/capabilities/destination-restrictions
with onboarding:write:
{"countries": ["EE", "GB"], "revision": 0}Use countries: null to remove only your optional restriction. An empty list
is refused. Use uppercase supported two-letter country codes within your
workspace's available destinations. A stale revision is refused; reload before
saving instead of overwriting another user's change. The restriction is checked
for calls, SMS and campaign admission; it does not hang up an existing call.
Syria is no longer on OpenPhonex's blanket country block. This does not remove targeted sanctions, acceptable-use rules, number restrictions, carrier routing requirements or pricing checks.
Workspace limits and higher-limit requests
Workspace limits separates Calling & messaging from Spending safeguards. It shows current operator spend/volume controls and the effective plan or operator allowance for simultaneous calls. Calls per day and simultaneous calls are different limits. Daily controls use a rolling 24-hour window.
- Wallet spending limits posted wallet spending plus a proposed operation. It is not your wallet balance.
- Voice spending is an admission estimate for voice operations. Final settlement uses actual metered usage; it is not an additional fee.
- Simultaneous calls limits calls active together. A phone number or carrier may impose a lower limit.
- Unique destinations counts distinct recipients in the rolling window.
Use Request higher limits to describe the volume or concurrency you need.
This creates an operator review without raising a cap, changing prices,
reserving funds or approving any calls. The API equivalent is
POST /v1/organizations/{organization_id}/capabilities/limit-requests
(onboarding:write) with a reason of 10–2,000 characters. It returns the
review ID and status.
The existing profile-request API remains available for explicit configuration and custom implementation-service requests. It is not required to choose an ordinary use case on the Capabilities page. Existing operator restrictions and custom review requirements remain in force.
Calling rules
An operator can attach calling rules to your record for a customer
application (today the payment_reminder rule set: effective period, local
calling windows, per-case cadence and attempt cap, script version, and the
stop / wrong-party / dispute actions). GET .../capabilities returns them as
calling_rules and whether they are enforced right now as
calling_rules_active. A self-serve request cannot set or clear them.
Authorized application batches
Any active workspace may run its own batches through the single-call API;
there is no per-profile campaign switch. Send each call with bulk: true,
your own batch label as campaign_id, and a user_authorization naming who
approved the batch. With a known relationship (the user_authorization
itself counts as user-requested; or declare relationship as
existing_customer, known_business, user_personal_contact, internal or
consented_contact) the call is an ordinary authorized call. A batch without
a non-empty user_authorization.authorized_by, or one that declares an
unknown relationship (user_requested: false and no relationship), is held
for review (needs_review.campaign); the custom implementation-services
profile holds every batch (needs_review.custom_always_review). Every other
gate still applies: blocked categories, sanctioned destinations, your
destination allowlist, caps and calling rules.
Campaigns
Campaigns are part of what every active workspace may do. A launch is checked
against your capabilities record and the outbound policy, in this order: a
sanctioned destination in the list blocks it (blocked_country); a suspended
workspace blocks it (workspace_suspended); a workspace that is not active
holds it (workspace_not_approved); voice missing from your channels holds it
(channel_not_enabled); a destination outside your allowlist holds it for the
usual first-use review (new_country_requires_review); a blocked purpose
blocks it (blocked_category.<token>); a missing consent basis blocks it
(consent_basis_required); and on the custom implementation-services profile
every launch is reviewed (needs_review.custom_always_review). The
campaigns_not_in_profile reason code no longer exists. Your caps are
enforced per call while the campaign runs, never at launch: the wizard's
review step shows each of these checks for the draft and how many days the
list takes under your daily call cap. See Campaigns.
The outbound sequence
Evaluate
→ evaluate_outbound_policy(...) # policy:evaluateReturns the policy decision and cost estimate before anything leaves the machine. This is a read — it changes nothing.
Get explicit human approval
Show the decision and cost to a human and wait for a clear yes. Never place a live call or send a live SMS on an implied approval.
Authorize and place
→ authorize_outbound(...) # policy:evaluate
→ create_outbound_call(...) # calls:writeSelf-hosted gateways use the same gate
A self-hosted gateway in local outbound mode does not call
create_outbound_call; it calls
POST /v1/gateway-deployments/{gateway_id}/outbound-calls with its own
deployment-bound token. That route runs the identical admission — the same
authorize_outbound decision, the same kill switches and caps, the same wallet
reserve — and only then mints the single-use authorization the host needs to
reach media. A blocked decision returns authorized: false with no
authorization, and the call is recorded as policy_blocked exactly as it would
be for a remote request. See Deployment modes for how
a deployment chooses its originator.
Blocked categories
The policy engine blocks outbound in these categories regardless of scope: healthcare, political, emergency, robocalling, mass outreach, telemarketing, lead generation, scraped / listed-contact broker campaigns, spoofing, and cold sales. Debt collection is not category-blocked — it is permitted subject to per-customer onboarding approval and the acceptable-use policy.
Broker example
A Czech contact-broker campaign that dials a purchased list is a
scraped/listed-contact broker category — evaluate_outbound_policy returns a
blocked decision, and create_outbound_call fails closed. The agent should
report the block and stop, not retry.