Automation rules

An automation rule changes tickets for you as messages arrive. Replyco tests every incoming message against each rule’s condition, in priority order, and when the condition holds it applies the rule’s action to the message’s ticket: set its status, archive it, give it a priority, assign it, mark it read or put it in a folder. Through the API a rule has one condition and one action.

Fields that matter

Field	Meaning
id	The rule’s id, for GET and PUT /openapi/messagerule/{id}.
ruleName	The rule’s name, shown in the app.
priority	Rules run from the lowest number up. 0, or leaving it out, puts the rule after all existing rules.
inActive	true switches the rule off.
condition	What to test: tableName and fieldName name the field, operator says how to compare, and value1 (with value2 for a range) what to compare with.
action	What to do: tableName and fieldName name the field to set and value the new value; or, with actionType 2, a row to add, such as a folder for the ticket.

The API reference for POST /openapi/messagerule lists every table and field a condition can test and an action can set, with the value format for text, numbers, dates, yes/no fields and ids. In short:

operator	Holds when
0 (default)	The field contains value1. Text only.
1	The field does not contain value1, or is empty. Text only.
2, 3	The field starts or ends with value1. Text only.
4	The field equals value1. Any type.
5	value1 ≤ field ≤ value2. Numbers and dates.

actionType	Effect
0 (default)	Sets fieldName of tableName to value, for example the ticket’s status.
2	Adds a row to tableName, with value as a JSON object, for example {"FolderId": "…"} to put the ticket in a folder.

Listing

GET /openapi/messagerule returns your company’s switched-on rules in priority order, in one list without pages. Switched-off rules are not in it; read them with GET /openapi/messagerule/{id}, which returns any rule and answers 404 for an unknown id. Keep the ids of rules you create, so you can find them again after switching them off.

A rule built in the Replyco app can have several conditions and actions. The API shows it by its first condition and first action, and a PUT replaces all of them with the one condition and action you send.

Creating and replacing

POST /openapi/messagerule creates a rule and answers with it; PUT /openapi/messagerule/{id} replaces one with the same body. This rule marks messages about product support reports as read:

curl -X POST https://open-api.replyco.com/openapi/messagerule \
  -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json" \
  -d '{"ruleName": "Mark support reports read", "condition": {"tableName": "Thread", "fieldName": "Subject", "value1": "product support report"}, "action": {"tableName": "Message", "fieldName": "Unread", "value": "false"}}'

{
  "ruleName": "Mark support reports read",
  "condition": { "tableName": "Thread", "fieldName": "Subject", "value1": "product support report" },
  "action": { "tableName": "Message", "fieldName": "Unread", "value": "false" }
}

{
  "id": "1d3f5a7c-9e2b-4d6f-8a0c-2e4f6a8c0e2b",
  "ruleName": "Mark support reports read",
  "priority": 7,
  "inActive": null,
  "condition": {
    "id": "4b6d8f0a-2c4e-4f6a-9b1d-3f5a7c9e1b3d",
    "tableName": "Thread",
    "fieldName": "Subject",
    "value1": "product support report",
    "value2": null,
    "relations": "Thread"
  },
  "action": {
    "id": "6e8a0c2e-4a6c-4e8a-8c0e-5a7c9e1b3d5f",
    "tableName": "Message",
    "fieldName": "Unread",
    "value": "false",
    "relations": null
  }
}

A request is checked before anything is saved, and every problem is answered with 400 and an error message naming it: a missing ruleName, condition, tableName, fieldName, value1, action or value; an unknown operator or actionType; a table or field that does not exist; a value that does not fit the field; or a folder that does not exist.

Each POST creates a new rule, so a retried create leaves two. There is no delete operation: to stop a rule, replace it with inActive set to true.

Operations

Method	Path	Summary	Scopes
GET	/openapi/messagerule	List automation rules	—
POST	/openapi/messagerule	Create an automation rule	—
GET	/openapi/messagerule/{id}	Get an automation rule by id	—
PUT	/openapi/messagerule/{id}	Update an automation rule	—

Errors

Status	Meaning	Returned by
400	The request is invalid; the body’s error says why.	POST /openapi/messagerule, PUT /openapi/messagerule/{id}
401	User is not authenticated or authorized.	GET /openapi/messagerule, POST /openapi/messagerule, GET /openapi/messagerule/{id}, PUT /openapi/messagerule/{id}
404	No rule with the given id exists.	GET /openapi/messagerule/{id}, PUT /openapi/messagerule/{id}

Related

• Autoresponders: reply automatically instead of changing the ticket.
• Folders: folder ids for a folder action.
• Users: user ids for an assignment action.
• API reference: every table, field and value format.