Help & Support

Getting started

This feature requires some familiarity with hosting your own scripts on the Web. Our code examples are in PHP, but you can use any platform and programming language you like, providing you can access HTTP POST data.

The Cbox webhook is an HTTP POST callback mechanism for getting a copy of new messages as they are posted to your Cbox. A couple of lines of PHP are sufficient to get started:

<?php
$input = @file_get_contents("php://input");
$json = json_decode($input);

// $json contains array of messages

error_log(print_r($json, true), 1, "your-email@example.com");

echo "OK";
?>

With the above code uploaded to your server, test that it works by opening the corresponding URL, e.g. https://yoursite.example.com/cbox.php, and confirming that you see "OK". You can then enter it as your callback URL in your Cbox settings.

When a user posts a message, Cbox will issue an HTTP POST request to your callback URL, with Content-Type application/json. The request body will look something like this:

[{"type":"message","box":802140,"channel":0,"time":1488526982,"uid":0,"name":"test","text":"this is a test","link":"","ip":"0.0.0.0"}]

The object is an array of messages. There can be multiple messages in a single POST. Your code can do whatever you like with the messages; it just needs to return an HTTP OK status to Cbox. Any response body is ignored.

Message contents

The message webhook is located after the message-accepted stage and before filtering. This means your endpoint will only receive messages that are being published on your Cbox (i.e. not messages from banned users). They will be "raw", having none of the built-in or custom filters applied (i.e. no boxcode expansion). Important to note is that messages can contain any UTF-8 character, and so should be escaped as appropriate before storage or display.

Message properties:

• type — always set to "message"
• box — your Cbox ID.
• channel — The channel ID to which the message was posted.
• id — The message ID.
• time — Unix times when the message was received.
• uid — Registered user ID. Guest IDs are undefined or zero.
• name — The user's name, as entered.
• text — The text of the message, as entered.
• link — Link associated with the message; the profile URL.
• ip — IP address of the user.

Errors and retry

Your endpoint needs to return an HTTP success header (status codes in the 2XX range) in response to the POST. If it returns any other status, or times out, Cbox will consider the delivery to have failed. On failure, Cbox will buffer messages for retry. Cbox will retry the POST at increasingly long intervals, even in the absence of further new messages.

Cbox buffers are not unlimited; if your endpoint is down for an extended time, the oldest messages may be dropped.

Notes

• Cbox ignores the body sent in response to the POST, and does not wait for it to complete.
• Return a 200 OK to Cbox as quickly as possible. Otherwise, there is a risk of a timeout, which will cause the same message(s) to be re-sent. If your message processing is slow, move it "offline", either by completing and flushing the HTTP response early and continuing to work, or by offloading incoming messages to another service.
• For forwards-compatibility, confirm that type == 'message' in your code; new event types may be supported in future.
• The box and channel properties mean you can multiplex several Cboxes to a single endpoint, and filter or switch based on channel.
• Message ID is a monotonically increasing number. Larger IDs are always newer messages.
• Although some properties are 32-bit integers, it's recommended that you treat all values as UTF-8 strings for storage or further processing.
• The POST request includes a custom HTTP header, X-Cbox-Time which contains the Unix timestamp at the moment the POST was sent. You can use this to calculate differential message times.