Third-Party Delivery

Third-Party Delivery lets you automatically send data to external systems (core banking, ERPs, payment gateways) whenever something happens in the platform — a customer is created, a transaction is approved, an account is updated. You configure what to send, where to send it, and how to transform the data. The system handles the rest: retries, error logging, and even capturing IDs that external systems send back.

How It Works (Big Picture)

The system has four building blocks:

1. Systems — The external systems you connect to (e.g. "T24 Core Banking", "SAP ERP").
2. External IDs — A lookup table that maps your internal records to their identifiers in external systems.
3. Hook Configs — Rules that say "when X happens to entity Y, send data to system Z."
4. Delivery Logs — A complete history of every delivery attempt, successful or not.

Here is the typical flow:

Something happens (e.g. a customer is created)
        ↓
The system checks: "Are there any hook configs for this event?"
        ↓
For each matching config:
  → Transform the data according to field mappings
  → Attach any known External IDs for this record
  → Send the HTTP request to the external system
  → Log the result (success or failure)
  → If the external system returns an ID, save it as an External ID

This entire process runs in the background. It never blocks the original operation — if a delivery fails, the user's action still succeeds.

Systems

A System represents an external API you want to send data to. Think of it as a connection profile.

What You Configure

Security

Authentication credentials are encrypted before being stored in the database and are never exposed through the API. They are only decrypted at the moment of delivery, inside the background processor.

Approval Workflow

Systems use a maker-checker workflow. When you create or edit a system, it starts in Draft status. You must submit it for approval before it becomes active. Only Authorized systems can be used for deliveries.

Draft → Submit for Approval → Pending Approval → Authorized
                                    ↓
                               Rejected (can edit and resubmit)

External IDs

External IDs solve a common integration problem: your system uses one ID for a record, and the external system uses a different one.

For example, a customer might be cust_abc123 in your system but CUS001 in T24. External IDs store this relationship so that deliveries can include the correct identifier for each system.

What You Configure

How They Connect to Deliveries

When a hook config has Include Third-Party IDs enabled (the default), the delivery engine automatically looks up all External IDs for the current entity and system, then attaches them to the outgoing payload under _thirdPartyIds:

{
  "customerName": "John Doe",
  "accountNumber": "ACC-001",
  "_thirdPartyIds": {
    "T24_CUSTOMER_ID": "CUS001",
    "T24_ACCOUNT_ID": "1234567"
  }
}

Automatic Capture from Responses

When a hook config is set to trigger on ON_CREATE and has Response Mappings configured, the system can automatically extract IDs from the external system's response and save them as External IDs. This means you only need to manually create External IDs for pre-existing records — new records get their external IDs captured automatically.

Hook Configs

A Hook Config is a rule that defines what data to send, when, and where. It ties together an entity type, an event, a system, and a set of field mappings.

What You Configure

Events

Hook configs trigger on these events:

Approval Workflow

Like Systems, Hook Configs also use a maker-checker workflow. Only Authorized and Active configs will trigger deliveries.

Field Mappings

Field mappings define how to translate your internal data into the format the external system expects. Each mapping has a source field (from your data) and a target field (in the outgoing payload).

Basic Example

If a customer record looks like this internally:

{
  "displayName": "John Doe",
  "email": "john@example.com",
  "customerNumber": "CUS-001"
}

And T24 expects this:

{
  "CUSTOMER.NAME": "John Doe",
  "EMAIL.1": "john@example.com",
  "MNEMONIC": "CUS-001"
}

Your field mappings would be:

Transforms

Sometimes you need to do more than just rename fields — you need to convert the data itself. Transforms are applied as a pipeline: each step takes the output of the previous step as its input.

Transform Pipeline Example

To send a date field to an external system that expects DD/MM/YYYY format as a string:

1. Source: createdAt (value: 2024-01-15T10:30:00Z)
2. Transform step 1: dateFormat with format DD/MM/YYYY → 15/01/2024
3. Transform step 2: toString → "15/01/2024"

If a transform fails (e.g. a date field contains invalid data), the system falls back to the raw value and records a warning — it does not stop the delivery.

Response Mappings

Response mappings let you automatically capture IDs from what the external system sends back. They only apply to ON_CREATE events.

Example

You send a new customer to T24. T24 responds with:

{
  "data": {
    "customerId": "T24-CUS-99001",
    "status": "ACTIVE"
  }
}

If your response mapping is:

The system will automatically create an External ID record:

• Entity Type: customer
• Entity ID: (the customer you just created)
• System: (the T24 system)
• External Key: T24_CUSTOMER_ID
• External Value: T24-CUS-99001

Next time you send data about this customer, that External ID will be automatically included in the _thirdPartyIds section of the payload.

Retries and Error Handling

The delivery engine distinguishes between errors that are worth retrying and errors that are permanent.

Retry Logic

Retries use exponential backoff based on the system's retry backoff setting. Each attempt is logged individually, so you can see the full retry history in the Delivery Logs.

What Gets Logged

Every delivery attempt creates a Delivery Log entry with:

• The full request (URL, method, headers, payload)
• The full response (status code, body, headers)
• Duration in milliseconds
• Attempt number and maximum attempts
• Error message if applicable
• A correlation ID that links all deliveries triggered by the same event

The Metadata Envelope

When Include Metadata is enabled (the default), the payload is wrapped in a standard envelope:

{
  "event": "ON_CREATE",
  "timestamp": "2024-01-15T10:30:00.000Z",
  "correlationId": "550e8400-e29b-41d4-a716-446655440000",
  "data": {
    "CUSTOMER.NAME": "John Doe",
    "EMAIL.1": "john@example.com",
    "_thirdPartyIds": {
      "T24_CUSTOMER_ID": "CUS001"
    }
  }
}

The correlationId is shared across all deliveries triggered by the same event. If creating a customer triggers hooks for three different systems, all three delivery logs will share the same correlation ID, making it easy to trace related deliveries.