Overview

Three operational primitives sit behind the support desk:

• Macros — canned replies. A macro carries a body with {{placeholder}} variables and, optionally, actions that are applied besides sending the text: set a status, add tags, assign a user.
• Tags — your tenant's tag vocabulary for tickets: a name, a display colour and a description.
• Routing rules — an ordered, first-match-wins triage list. Each rule ANDs a set of conditions over a fixed six-field allowlist and, when it matches, applies actions.

Authentication

Authorization: Bearer cm_your_api_key

POST /routing-rules/evaluate is a dry run — it writes nothing, so it needs only the read scope. POST /macros/{id}/use increments a counter, so it needs write.

Macros

The macro object

{
  "id": "9b8a…",
  "tenant_id": "a0b1…",
  "name": "Refund acknowledged",
  "body": "Hi {{customer_name}}, your refund for order {{order_id}} is on its way.",
  "actions": { "set_status": "pending", "add_tags": ["refund"], "assign_to": null },
  "category": "billing",
  "is_active": true,
  "usage_count": 41,
  "created_at": "2026-08-01T10:00:00Z",
  "updated_at": "2026-08-16T14:00:00Z"
}

actions

Unknown keys inside actions are rejected with 422 rather than ignored, so a typo cannot silently do nothing.

GET /api/v1/support/ops/macros

Ordered by usage_count descending, then name — so the picker shows what your team actually uses.

POST /api/v1/support/ops/macros

409 A macro named '…' already exists on a duplicate name.

PATCH / DELETE /api/v1/support/ops/macros/{macro_id}

PATCH takes the same fields, all optional; sending actions: null clears the actions. DELETE returns 204.

POST /api/v1/support/ops/macros/{macro_id}/use

Renders the macro against a context and bumps usage_count.

curl -X POST https://api.callmissed.com/api/v1/support/ops/macros/9b8a…/use \
  -H "Authorization: Bearer cm_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "context": { "customer_name": "Asha", "order_id": "A-4419" } }'

{
  "id": "9b8a…",
  "name": "Refund acknowledged",
  "body": "Hi Asha, your refund for order A-4419 is on its way.",
  "actions": { "set_status": "pending", "add_tags": ["refund"] },
  "usage_count": 42
}

Placeholder syntax is {{name}}, where the name starts with a letter or underscore. Values are truncated to 500 characters.

Unknown or null-valued placeholders are left verbatim — {{order_id}} stays in the text rather than becoming an empty gap. Check the rendered body before sending it to a customer, or supply every variable the macro declares.

Applying the returned actions is your job: this endpoint renders and counts, it does not mutate a ticket.

Tags

{
  "id": "7f6e…",
  "tenant_id": "a0b1…",
  "name": "refund",
  "color": "#c2410c",
  "description": "Money going back to the customer",
  "created_at": "2026-08-01T10:00:00Z",
  "updated_at": "2026-08-01T10:00:00Z"
}

GET is ordered by name and takes limit (1..500, default 100) and offset (0..100000). There are no filters.

Anything other than a hex triplet returns 422 color must be a hex triplet like '#aabbcc'.

Routing rules

Vocabulary

The field list is a closed allowlist — an unknown field is 422, not a silently-false condition.

Condition value rules

The rule object

{
  "id": "2c3d…",
  "tenant_id": "a0b1…",
  "name": "Enterprise urgent → Ravi",
  "position": 0,
  "conditions": [
    { "field": "priority", "operator": "eq", "value": "urgent" },
    { "field": "contact_email_domain", "operator": "in", "value": ["acme.com", "globex.com"] }
  ],
  "assign_to_user_id": "b1f2…",
  "assign_strategy": "direct",
  "set_priority": "urgent",
  "add_tags": ["enterprise"],
  "is_active": true,
  "created_at": "2026-08-05T09:00:00Z",
  "updated_at": "2026-08-05T09:00:00Z"
}

All conditions on a rule are ANDed. Rules are evaluated in position order and the first match wins — position is the policy, so the list is never re-sorted for you.

GET /api/v1/support/ops/routing-rules

Ordered by position. Takes is_active, limit (1..500, default 100) and offset (0..100000).

POST /api/v1/support/ops/routing-rules

A rule with an empty conditions array matches everything — use it deliberately as a final catch-all at the highest position.

PATCH /api/v1/support/ops/routing-rules/reorder

Rewrites the whole evaluation order.

New position is the array index. A partial list returns 422 rule_ids must list every routing rule in this tenant exactly once — reordering is all-or-nothing, so two concurrent partial reorders cannot interleave into a nonsense order.

POST /api/v1/support/ops/routing-rules/evaluate

A dry run. Nothing is written; you get back what would happen.

Every field is optional. An absent fact fails any condition that asks about it — so send the whole picture when testing.

curl -X POST https://api.callmissed.com/api/v1/support/ops/routing-rules/evaluate \
  -H "Authorization: Bearer cm_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "whatsapp",
    "priority": "urgent",
    "subject": "Cannot check out",
    "contact_email": "asha@acme.com",
    "tags": ["vip"]
  }'

{
  "matched": true,
  "rule_id": "2c3d…",
  "rule_name": "Enterprise urgent → Ravi",
  "assign_to_user_id": "b1f2…",
  "assign_strategy": "direct",
  "set_priority": "urgent",
  "add_tags": ["enterprise"]
}

Only is_active: true rules are considered. When nothing matches you get {"matched": false, …, "add_tags": []} — a miss, not an error.

PATCH / DELETE /api/v1/support/ops/routing-rules/{rule_id}

Same fields as create, all optional. DELETE returns 204.

Errors

Nothing on this page consumes credits.