Configure Application Callbacks

Overview

Callbacks let CX Platform tell another system what just happened with a document, automatically and in real time. When a message is successfully delivered or hits an error along the way, the platform fires an HTTP request to a URL you nominate, so your CRM, registry, or other connected system can react straight away.

This is typically used for realtime API integrations, where you need delivery confirmations or failure notifications to flow back into the system that submitted the document in the first place. No polling, no manual checks, no waiting around.

To configure callbacks for an Application:

1. In the secondary navigation menu, click Applications to view a list of all available Applications.
2. Open the Application you want to configure, then click the Callbacks tab.

What triggers a callback

Two events fire a callback, and each has its own URL and payload, so you can route them to different endpoints if it suits your setup.

Success — the message was successfully delivered. Good to know: a successful delivery can still bounce later, so a success callback isn't a guarantee that the recipient has the message in hand for good.

Error — something went wrong. This covers failures to import (e.g. missing fields), failures to compose (e.g. a template referencing fields that are blank or null), and failures to send (e.g. a bounce at send time).

‍

Pass document data through with placeholders

You can reference fields from the submitted document anywhere in your URL or payload using %%FIELD%% syntax. So if your document includes a CustomerId field, drop %%CustomerId%% into your URL or template and the platform will swap in the real value when the callback fires.

On top of your own fields, there's a set of CX Platform fields you can reference in any callback:

‍
Configure a callback

Once you're on the Callbacks tab, you'll see a single form covering both success and error events. Work through it from top to bottom.

1. Choose your Template type from the dropdown — for example, Plain text or whichever format your receiving system expects.
2. Add any HTTP headers in the Headers (one per line) field. These are static and aren't replaced by document fields, so they're typically used for authentication tokens like Authorization: JWT.
3. Enter your Success callback URL. This is where successful delivery notifications will be posted.
4. If you need to send a custom payload body on success, enter it in the Success callback template field. Use %%FIELD%% syntax to include document or platform values.
5. Enter your Error callback URL. This is where failure notifications will be posted.
6. If you need a custom payload body on error, enter it in the Error callback template field, again using %%FIELD%% syntax for any dynamic values.
7. Click Save.

That's it — your Application is now wired up to notify your external system in real time. Every future send will fire a callback based on these settings, so the receiving system stays in step with what's happening in CX Platform.

‍

Test before you go live
‍Before pointing callbacks at your production system, it's worth firing a few test sends and confirming the receiving end gets exactly what it expects. A quick request bin or staging endpoint will save you from chasing payload issues later.

‍