phone_filter_mode or its imessage_filter_mode alias and omit rule direction. New rules then apply to both directions. An active applicable allow or block takes precedence in either mode. Numbers without an applicable choice follow the direction’s mode:
imessage_filter_mode: "whitelist": unmatched numbers are denied.imessage_filter_mode: "blacklist": unmatched numbers are permitted.
phone_inbound_filter_mode and phone_outbound_filter_mode on the identity for independent defaults. There is no separate iMessage directional mode pair. Inbound is from the external party to the agent; outbound is from the agent to that party. Only rules covering the relevant direction apply. See Manage identities. Rules match exact E.164 phone numbers (match_type: "exact_number"). New directional SDK/CLI options require 0.7.3 or later.
Direction and rule identity
Companion mode supports conversation-only sponsorship in eligible dedicated-line groups. It does not change shared-line connections or global number permissions. An applicable block on any group participant vetoes Companion permission in that direction. An eligible introducing sender needs active exact-number allows in both directions under the shared phone policy. Defaults or access to another Companion conversation do not qualify. Their own authenticated message in the verified group activates the scope; merely appearing in its participant list does not.- Create defaults to
direction: "both". PATCH without direction preserves coverage. - List
direction=inboundoroutboundincludesbothrules.direction=bothselects only bidirectional rules. Omit direction for all rules without duplicates. Action and match-type filters apply independently before pagination. A2A filters remain exact matches with their existing defaults. - Compatible new coverage widens the existing rule to
both. Matching actions and lifecycle states consolidate even after editing two existing rules. Previously issued IDs remain usable for get, update, and delete of the consolidated logical rule. Lists include it once; an ID does not permanently denote its original direction. - POST returns
201, including widening. Use the returned ID and direction; a new ID is not guaranteed. PATCH returns200. - Duplicate coverage returns
409withrule_already_existsandexisting_rule_id. Conflicting actions also return409; create does not overwrite them. Paused coverage is not silently reactivated or combined with active coverage. - A
bothrule has one action. Use separate one-way rules for opposing actions. Inbound permission does not imply permission to reply.
403. Review message listing for blocked-message access.
Shared-line connections
Establishing or re-establishing a shared-line connection requires effective inbound and outbound permission for that person, along with the existing setup requirements. Defaults can supply those permissions; an explicitboth rule is not required. Connecting never adds an allow rule, widens a rule, or changes a mode.
An existing connection is not automatically disconnected when rules change. Subsequent traffic checks its own direction; reconnecting checks both again. Dedicated-line traffic keeps per-direction checks rather than inheriting the shared-line setup requirement. Sending still requires consent and a ready channel.
Auth. Claimed agent keys can read their permitted rules. Creating, updating, or deleting rules requires an admin API key or the Inkbox Console. Agent writes return 403. Org-wide listings require administrative access.
List contact rules
agent_handle. Another handle returns 403; agent keys cannot create rules.
Path parameters
Query parameters
Response (200)
JSON
Code examples
Create contact rule
Path parameters
Request body
Request example
JSON
Response (201)
Returns the saved rule, which may be an existing rule widened toboth. See Contact rule object.
Error responses
Code examples
Get contact rule
Path parameters
Response (200)
Returns the rule. See Contact rule object.Error responses
Update contact rule
Path parameters
Request body
Supplyaction, direction, or both. apply_to requires action and excludes direction. Supplied values cannot be null.
Request example
JSON
Response (200)
Returns the updated rule. On aboth allow, {"action":"block","apply_to":"inbound"} blocks inbound and preserves outbound allow atomically. Refresh the list to see the preserved opposite-side rule; the response contains the addressed rule. Applying the current action does not split it.
In contrast, {"direction":"inbound"} removes outbound coverage and lets remaining rules and the outbound default decide sending permission. An action-only PATCH changes all current coverage.
Error responses
Delete contact rule
Path parameters
Response (204)
No content.Error responses
List org iMessage contact rules
Query parameters
Response (200)
Returns alist[ContactRule] ordered newest first.
Code examples
Contact rule object
List, get, create, update, and organization-wide list responses include a nullablecontact card for an exact target with one resolved owner in the rule’s
organization. The card follows the caller’s contact permissions
and contains no memories, memory_count, or latest_memory. Unresolved,
ambiguous, and inaccessible matches return null.
Reads resolve the current contact. An idempotent write replay preserves its
original response snapshot. SDK/CLI 0.6.11 supports these cards; CLI tables show
contact names and JSON output preserves the card.
Additional resources
- iMessage guide — filtering
- Manage identities — set
imessage_filter_mode - Phone contact rules: alternative routes for the same phone communication list

