General API¶
A Backendless application can publish messages to Backendless for subsequent distribution to subscribers. A message must be published to a channel. Backendless supports unlimited number of channels per application. Channels can be used as a filtering mechanism - subscribers see the messages published only to the channel they subscribe to.
There is only one API for all types of message publishing. It supports the following scenarios:
- Basic message publish
- Publishing with headers - can be used for conditional delivery
- Delayed publishing
- Repeated publishing
Method¶
POST
Endpoint URL¶
The xxxx.backendless.app is a subdomain assigned to your application. For more information see the Client-side Setup section of this documentation.
https://xxxx.backendless.app/api/messaging/<channel-name>
where:
| Argument | Description |
|---|---|
<channel-name> |
name of the channel to publish the message to. |
Request Headers¶
Content-Type: application/json
user-token: optional value obtained as a result of the login operation.
where:
| Argument | Description |
|---|---|
Content-Type |
Must be set to application/json. This header is mandatory. |
user-token |
Optional header. Contains a value returned by Backendless in a preceding user Login API call. If user-token is set in the request, the operation will be executed with the security policy associated with the currently logged in user. This means all the permissions and roles assigned to the user will be enforced by Backendless. |
Request Body:¶
Optional parameters are shown in [square brackets]:
{
"message" : value,
["publisherId" : value,]
["headers": {"key1":"value1","key2":"value2"},]
["publishAt":timestamp,] *// the value in milliseconds*
["repeatEvery":frequency-in-seconds,]
["repeatExpiresAt":expiration-timestamp] *// the value is to be in milliseconds*
}
where:
| Argument | Description |
|---|---|
headers |
Contains message headers. Headers deliver additional content to subscribers, but also may be referenced by subscribers for message filtering purposes. See the Publish with Headers section for an example. Additionally, see the Conditional Delivery section for information on how to use headers to filter delivered messages. |
publishAt |
Optional property. If present, must be a timestamp when the message should be delivered to subscribers. |
releatEvery |
Optional property. If present, must be a number of seconds defining the frequency of sending the message. |
repeatExpiresAt |
Optional property. If present, must be a timestamp when the repeat publishing of the message must stop. |
Response Body¶
{
"status" : "scheduled" | "failed",
"messageId": messageId
}
In order to obtain message delivery status, use the Get Message Status API with the messageId value returned by the message publishing request.
Errors¶
When the server-side reports an error, it returns a JSON object in the following format:
{
"message":error-message,
"code":error-code
}
The following errors may occur during the message publishing API call:
| Error Code |
Description |
|---|---|
| 5003 |
Invalid repeatExpiresAt date |
| 5007 |
User does not have the permission to publish messages |
| 5030 |
Invalid publishAt date |