TemplateRpc
TemplateRpc provides the RPC interface for listing, creating, updating, deleting, and inspecting message templates. It delegates all template persistence and tag aggregation work to TemplateService, while applying request validation through Zod schemas.
Endpoints
POST /api/rpc (Method: TemplateRpc.getData)
Description: Lists message templates.
Request Body:
{
"method": "TemplateRpc.getData",
"params": {
"filter": {},
"sort": {},
"page": 1,
"pageSize": 25
}
}Parameters:
| Name | Type | Required | Description |
|---|---|---|---|
filter |
Object |
No | Optional query filter object. The schema allows arbitrary object properties. |
sort |
Object |
No | Optional sort object. The schema allows arbitrary object properties. |
page |
Number |
No | Page number. Must be a positive integer. Defaults to 1 when omitted. |
pageSize |
Number |
No | Number of items per page. Must be a positive integer. Defaults to 25 when omitted. |
Response:
{
"success": true,
"data": {
"data": [],
"totalCount": 0
}
}The RPC returns the value produced by TemplateService.getTemplates(filter, options, context). The service implementation returns an object with a data array and a totalCount number.
Example (cURL):
curl -X POST "${APP_BASE_URL}/api/rpc" \
-H "Content-Type: application/json" \
-d '{
"method": "TemplateRpc.getData",
"params": {
"page": 1,
"pageSize": 25
}
}'POST /api/rpc (Method: TemplateRpc.create)
Description: Creates a new message template.
Request Body:
{
"method": "TemplateRpc.create",
"params": {
"...": "template fields"
}
}Parameters:
| Name | Type | Required | Description |
|---|---|---|---|
| Template fields | Object |
Yes | The request body must satisfy OmniTemplateSchema with _id, createdAt, updatedAt, and subscriptionId omitted. The exact field set, optionality, defaults, and validation rules are defined in OmniTemplateSchema. |
Response:
{
"success": true,
"data": {
"_id": "string",
"...": "submitted template fields",
"subscriptionId": "string",
"createdAt": "date-time",
"updatedAt": "date-time"
}
}The RPC returns the result of TemplateService.createTemplate(data, context). Based on the service implementation, the created document is stored with the current subscriptionId from the request context and timestamps for createdAt and updatedAt.
This method is associated with billing metadata for template creation. The billing configuration is declared in the RPC decorator, but the runtime billing effect depends on the framework’s billing integration.
Example (cURL):
curl -X POST "${APP_BASE_URL}/api/rpc" \
-H "Content-Type: application/json" \
-d '{
"method": "TemplateRpc.create",
"params": {
"...": "template fields"
}
}'POST /api/rpc (Method: TemplateRpc.update)
Description: Updates an existing message template.
Request Body:
{
"method": "TemplateRpc.update",
"params": {
"_id": "string",
"...": "partial template fields"
}
}Parameters:
| Name | Type | Required | Description |
|---|---|---|---|
_id |
String |
Yes | Identifier of the template to update. |
| Partial template fields | Object |
No | Any other fields are taken from OmniTemplateSchema.partial(). The exact field set, optionality, defaults, and validation rules are defined in OmniTemplateSchema. |
Response:
{
"success": true,
"data": {
"_id": "string"
}
}The RPC returns the value produced by TemplateService.updateTemplate(data, context). The service updates the matching template within the current subscription scope, refreshes updatedAt, and then returns the stored template document.
If no matching record is found within the request scope, the service throws an error with the message Template not found or access denied.
Example (cURL):
curl -X POST "${APP_BASE_URL}/api/rpc" \
-H "Content-Type: application/json" \
-d '{
"method": "TemplateRpc.update",
"params": {
"_id": "66b9f0b0c2a0d6b7f0000001",
"subject": "Updated subject"
}
}'POST /api/rpc (Method: TemplateRpc.delete)
Description: Deletes a message template.
Request Body:
{
"method": "TemplateRpc.delete",
"params": {
"_id": "string"
}
}Parameters:
| Name | Type | Required | Description |
|---|---|---|---|
_id |
String |
Yes | Identifier of the template to delete. |
Response:
{
"success": true,
"data": {
"success": true
}
}The RPC returns the value produced by TemplateService.deleteTemplate(_id, context). The service deletes a template within the current subscription scope and returns an object containing a boolean success field.
This method is associated with billing metadata for deletion. The billing configuration is declared in the RPC decorator, but the runtime billing effect depends on the framework’s billing integration.
Example (cURL):
curl -X POST "${APP_BASE_URL}/api/rpc" \
-H "Content-Type: application/json" \
-d '{
"method": "TemplateRpc.delete",
"params": {
"_id": "66b9f0b0c2a0d6b7f0000001"
}
}'POST /api/rpc (Method: TemplateRpc.getTemplateTags)
Description: Gets all unique tags used across all templates.
Request Body:
{
"method": "TemplateRpc.getTemplateTags",
"params": {}
}Parameters:
| Name | Type | Required | Description |
|---|---|---|---|
| None | - |
No | This method does not accept request parameters. |
Response:
{
"success": true,
"data": [
{ "value": "tag-a", "label": "tag-a" },
{ "value": "tag-b", "label": "tag-b" }
]
}The RPC returns an array of tag option objects. TemplateService.getTemplateTags(context) gathers unique values from the tags field across templates, sorts them, and TemplateRpc maps each string into an object with value and label properties.
Example (cURL):
curl -X POST "${APP_BASE_URL}/api/rpc" \
-H "Content-Type: application/json" \
-d '{
"method": "TemplateRpc.getTemplateTags",
"params": {}
}'Notes
The RPC methods in this class do not declare explicit transport middleware in the source shown. Authentication, session scope, and tenant scoping should therefore be treated as framework/runtime concerns unless confirmed elsewhere. The service methods inspected here use context.subscriptionId to scope create, update, delete, and list operations to the current subscription.
TemplateRpc.create and TemplateRpc.delete include billing metadata in their decorators. That metadata is declarative and should not be treated as proof of a specific billing side effect without inspecting the framework billing integration.