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.

StatusMeaning
Not activatedThe workspace has not cleared verification yet. Outbound is refused.
Pending reviewA 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.
ActiveOutbound calls and SMS are authorized within the profiles, channels, destinations and caps on the record.
SuspendedAn 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:evaluate

Returns 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:write

Self-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.

On this page