All available operations for sending and manipulating notifications
This endpoint creates and sends a notification.
HTTP Request
POST https://api.cord.com/v1/notifications
Request Body
Field | Type | Description |
---|---|---|
actor_id |
string |
required ID of user who is the “actor” sending the notification |
recipient_id |
string |
required ID of user who is receiving the notification |
template |
string |
required Template for the header of the notification. The expressions {{actor}} and {{recipient}} will be replaced respectively with the notification’s actor and recipient. (See below for an example.) Currently, it is a requirement that all notifications are “from” an actor, and so the template is required to contain at least one instance of {{actor}} . |
url |
string |
required URL of page to go to when the notification is clicked |
type |
string |
required Currently must be set to url ; in the future this may define different types of notifications, but for now only url is defined |
Example Request
In this example, suppose a user with the ID alice
and name “Alice Applegate”
exists, as well as another user with the ID bob
and name “Bob Bloke”. Here is
an example request to send a notification from Alice to Bob. When Bob receives
this notification, it will say “Alice Applegate sent Bob Bloke a delicious
sandwich”, and will go to http://www.example.com/
when Bob clicks it.
curl "https://api.cord.com/v1/notifications" \
-X POST \
-H 'Authorization: Bearer <ACCESS_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"actor_id": "alice",
"recipient_id": "bob",
"template": "{{actor}} sent {{recipient}} a delicious sandwich",
"url": "http://www.example.com/",
"type": "url"
}'
If successful, the response will be:
{
"success": true,
"message": "Notification created.",
"notificationID": "<NEW_ID>"
}
Current Limitations
template
must have the {{actor}}
expression. We anticipate
lifting this restriction in the future as well.On this page