Event Scripting

Event Scripting allows users to write scripts that run when certain system events happen. Scriptable events, a.k.a process events, are "fired" when certain parts of the API are called, externally by clients, or internally by other scripts. Events are generated for all services and most resources defined by those services.

Types of Events

API-generated events typically take the form of

service_name[.resource_name].verb

where service is the API name of the service, resource is the optional resource path ('/' replaced with '.') and the verb is the HTTP verb used in the request.

System Resources

The system service generates a lot of events, for example, for the root retrieval of resources...

• system.get

for common resources like admin, app, app_group, custom, cors, roles, services, users...

• system.service.get,
• system.service.post,
• system.service.patch,
• system.service.delete,
• system.service.{id}.get,
• system.service.{id}.patch,
• system.service.{id}.delete,

some others include...

• system.cache.delete,
• system.cache.{service}.delete,
• system.config.get,
• system.config.post,
• system.constant.get,
• system.constant.{type}.get,
• system.environment.get,
• system.event.get,
• system.event.{event_name}.get,
• system.event.{event_name}.post,
• system.event.{event_name}.delete,
• system.service_type.get,
• system.script_type.get,
• system.package.get,
• system.package.post,

Database Services

db.get, db._schema.get, db._schema.post, db._schema.put, db._schema.patch, db._schema.{table_name}.get, db._schema.{table_name}.post, db._schema.{table_name}.put, db._schema.{table_name}.patch, db._schema.{table_name}.delete, db._schema.{table_name}.{field_name}.get, db._schema.{table_name}.{field_name}.put, db._schema.{table_name}.{field_name}.patch, db._schema.{table_name}.{field_name}.delete, db._table.get, db._table.{table_name}.get, db._table.{table_name}.post, db._table.{table_name}.put, db._table.{table_name}.patch, db._table.{table_name}.delete, db._table.{table_name}.{id}.get, db._table.{table_name}.{id}.put, db._table.{table_name}.{id}.patch, db._table.{table_name}.{id}.delete,

File Services

files.get, files.post, files.patch, files.delete, files.{folder_path}.get, files.{folder_path}.post, files.{folder_path}.patch, files.{folder_path}.delete, files.{file_path}.get, files.{file_path}.post, files.{file_path}.put, files.{file_path}.patch, files.{file_path}.delete,

Auth Services

user.get, user.password.post, user.profile.get, user.profile.post, user.register.post, user.session.get, user.session.post, user.session.delete, user.custom.get, user.custom.post, user.custom.patch, user.custom.delete, user.custom.{id}.get, user.custom.{id}.patch, user.custom.{id}.delete,

HTTP Services

HTTP Services, by default, fire no events unless there are paths defined in the Open-API/Swagger Specification. In that case, events are generated based on calls matching paths defined. myservice.makes.count.get would be generated for a call to GET http://example.com/api/v2/myservice/makes/count.

SOAP Services

SOAP Services fire events based on the methods defined in the given WSDL file. For example, myservice.call_method.post would be generated for a call to POST http://example.com/api/v2/myservice/call_method.