API Architecture in T24: From OFS to IRIS to REST

For decades, T24 integration has been dominated by a single approach: send a command string through OFS, wait for a response, and hope it worked. The approach works, it is battle-tested, and it is still the most common way to get data into and out of T24. But it is not the only way, and increasingly, it is not the best way for every use case.

As T24 deployments have grown more complex, the integration surface has expanded. Banks now need to connect T24 to web portals, mobile apps, CRM systems, payment hubs, and analytics platforms — each with different requirements for latency, data format, and reliability. The one-size-fits-all OFS interface no longer covers every scenario. The result is a layered API architecture that gives integration teams multiple options.

This article maps the API landscape in Temenos Transact — what exists, when each option makes sense, and where the boundaries are between API calls and event-driven integration. If you are here for event streaming specifically, the sister article Real-Time Event Architecture in T24 covers Kafka, event publishing, and stream processing in depth.

The API landscape in T24

Temenos Transact exposes its business functionality through several distinct API layers, each designed for a different type of integration. Understanding which one to use — and when — is the first step toward building integrations that are maintainable, performant, and appropriate for the task.

OFS — the workhorse

OFS (OfsCommand Service) is the oldest and most widely used T24 API. It accepts command strings in a proprietary format and returns responses in the same format. OFS can do almost anything — create a customer, post a transaction, run a report, query account details. It is the lowest common denominator of T24 integration, and every T24 system supports it, whether you are on R14, R20, or the latest release.

OFS works well for server-to-server communication where both sides understand the T24 data model and command syntax. It is fast, it is synchronous, and it returns results immediately. The downside is the format — parsing OFS responses has been described as "reading tea leaves but with more semicolons." Each integration needs to handle the exact response format, error codes, and multi-value field structures. If you are connecting a modern web application to T24, you probably do not want your frontend team writing OFS parsers. That is what the higher-level API layers are for.

SOAP web services

T24 has supported SOAP web services since the R12 era, exposing business operations through WSDL-defined endpoints. SOAP provides a structured, XML-based interface with formal contracts, error handling, and security standards (WS-Security). It is still widely used in banks that have existing SOAP infrastructure, enterprise service buses, or regulatory requirements for formal message schemas.

The advantage of SOAP is its strict contract — the WSDL defines exactly what operations are available, what data they expect, and what they return. The disadvantage is complexity. A simple customer creation request requires a SOAP envelope, headers, potentially WS-Security tokens, and an XML payload that is significantly larger than the equivalent OFS command or REST call. SOAP integrations are reliable and well-documented, but they are expensive to build and maintain. Most new integrations choose REST instead.

REST APIs and IRIS

The modern approach is REST — lightweight, JSON-based, and designed for the way web and mobile applications consume APIs. Instead of sending an OFS command string, an external system calls POST /api/customer with a JSON payload and gets a JSON response. The Temenos Integration Framework (IRIS) handles the translation between the REST API and the underlying T24 operation — whether that is an OFS call, a routine invocation, or a database query.

REST APIs are the preferred choice for new integrations in most banks today. They are easier to document, easier to test, and easier for developers who do not know T24 to work with. The trade-off is that REST APIs require IRIS (or a similar API gateway), which adds a layer between the consumer and T24. For simple, server-to-server operations that are already well-served by OFS, the REST layer adds overhead without much benefit. For customer-facing applications, omnichannel portals, and mobile apps, REST is the clear right answer.

Temenos Integration Framework (IRIS)

IRIS is Temenos's API gateway and integration framework. It sits between T24 and external systems, providing a standardised way to expose T24 data and functionality through REST APIs. It is not a separate product you install — it is a framework that runs within the T24 ecosystem, using the same security model, the same data model, and the same operational processes.

The primary function of IRIS in the API layer is API exposure and mediation. Instead of sending an OFS string and parsing the response, an external system calls a REST endpoint with JSON and receives JSON back. IRIS handles the translation between the REST API and the underlying T24 operation — an OFS call, a routine invocation, or a database query. The external system does not need to know anything about T24 internals. It just sends JSON and receives JSON.

IRIS also handles cross-cutting concerns like authentication, rate limiting, request logging, and response transformation. This means your API consumers get a consistent experience regardless of which T24 operation they are calling, and you can change the underlying T24 implementation without breaking the API contract — as long as the JSON schema stays the same. For teams building customer-facing applications or third-party integrations, this decoupling is the main reason to adopt IRIS instead of exposing OFS directly.

One important distinction: IRIS supports both synchronous API calls (request-response, which is what this article covers) and event publishing (emit-and-forget, which is covered in the event architecture article). These are different integration patterns with different trade-offs, and choosing between them is one of the key architectural decisions your team will need to make.

When to use each API pattern

Having multiple API options means you need criteria for choosing between them. The wrong choice leads to over-engineered integrations (using REST for a simple server-to-server OFS call that has worked for years) or under-engineered ones (using OFS for a customer-facing mobile app that needs JSON responses and proper error handling). Here is a practical decision framework.

Use OFS when

OFS is the right choice for server-to-server communication where both systems know T24 — internal batch jobs, integration with T24-based tools, and operations that need maximum performance with minimum overhead. If you are calling T24 from another T24 system, from a jBC routine, or from a Java service that already has OFS parsing logic, there is no reason to add a REST layer. OFS is also the fallback when IRIS is not available or when you need to call a T24 routine that has no REST equivalent.

Use SOAP when

SOAP is worth considering when regulatory or enterprise architecture requirements mandate formal contracts, WS-Security, or integration with an existing enterprise service bus. If your bank has a central SOA governance board that approves all integration contracts, SOAP gives you the formal definition they require. For new integrations that do not have these constraints, REST is almost always simpler and faster to deliver.

Use REST when

REST (through IRIS) is the right choice for customer-facing applications, mobile apps, third-party integrations, and any scenario where the consuming system does not have T24-specific knowledge. If you are building a web portal, a mobile banking app, or an API for external partners, REST is the standard that your consumers expect. REST also makes integration testing easier — your QA team can use standard HTTP tools like Postman or curl instead of needing specialised T24 OFS testing tools.

API calls vs. event streaming

An important architectural decision is whether to use synchronous API calls (request-response) or event streaming (publish-subscribe). API calls are appropriate when the consumer needs an immediate response — a frontend application looking up customer details, a payment service verifying account balances before processing a transaction. Event streaming is appropriate when the consumer needs to react to business events without waiting for a response — downstream systems that need to know about every new transaction, fraud detection systems, and analytics pipelines.

If you are evaluating event streaming, the Real-Time Event Architecture in T24 article covers Kafka integration, event publishing through IRIS, and the operational considerations of running an event-driven T24 infrastructure.

Operating T24 APIs

Adding an API layer on top of T24 changes how your integration team works. Operations teams that are used to monitoring OFS response times and file transfer schedules need to learn HTTP status codes, latency percentiles, and rate limiting. But the operational model for T24 APIs is not fundamentally different from running any other API gateway — the main difference is that the backend is T24, which has its own performance characteristics and constraints.

Key operational considerations for T24 APIs:

• Authentication. IRIS can integrate with LDAP, Active Directory, or OAuth providers. API consumers authenticate once and receive a token, rather than sending credentials with every request as OFS does. This is better for security and better for audit trails.
• Rate limiting. T24 has finite processing capacity. A misbehaving API consumer can overwhelm the system. IRIS supports rate limiting per consumer, which prevents one noisy integration from affecting others. If you have ever had to explain why a single misconfigured script caused T24 to become unresponsive, you already know why this matters.
• Monitoring. API monitoring is different from OFS monitoring. You need to track request volume, error rates, latency percentiles (p50, p95, p99), and consumer-specific metrics. Standard API monitoring tools (Datadog, Prometheus, New Relic) work with IRIS through its logging and metrics endpoints.
• Versioning. REST APIs need versioning strategies. Adding a field to a JSON response is a non-breaking change. Renaming or removing a field is breaking. IRIS allows you to maintain multiple API versions simultaneously, which gives consumers time to migrate. This is a significant improvement over OFS, where changing the response format breaks every consumer at the same time.

API skills for T24 teams

Moving from classic OFS-based integration to a layered API architecture requires some new skills, even for experienced T24 professionals. None of these are difficult to learn, but they represent a different way of thinking about integration.

API design.

In the traditional OFS model, you design command strings and response parsing logic. In the REST model, you design endpoints, request schemas, and response schemas. What resources does your API expose? What fields does each endpoint return? What happens when a required field is missing? These are design decisions that affect every consumer of the API, and getting them right requires thinking from the consumer's perspective rather than from T24's internal data model. A well-designed T24 API hides the complexity of multi-value fields and internal IDs from consumers.

Error handling.

OFS returns error codes in a response string. REST APIs return HTTP status codes (200, 400, 401, 500) with structured error bodies. API consumers expect consistent error formats — every error should include a code, a message, and optionally a details field. This is more predictable for consumers than parsing OFS error strings, but it means your API layer needs to map T24 errors to appropriate HTTP responses. A T24 validation error becomes a 400. An authentication failure becomes a 401. A timeout becomes a 504. The mapping sounds simple, but getting it right for every operation requires careful testing.

Testing.

Testing REST APIs against T24 is easier than testing OFS integrations. Standard HTTP testing tools — Postman, curl, REST clients, automated test frameworks — work with T24 REST APIs without modification. You can write integration tests that call the API, validate the JSON response, and check that the underlying T24 record was created correctly. This is a significant improvement over OFS testing, which typically requires specialised tools or direct T24 access.

Documentation.

REST APIs should be documented with OpenAPI (formerly Swagger). IRIS can generate OpenAPI specifications from your API definitions, which means your consumers get interactive API documentation without manual effort. Good API documentation includes example requests and responses, error codes, and rate limit headers. If your API consumers need to call your support team to understand how to use the API, your documentation is incomplete.

The bottom line

T24 offers a layered API architecture — OFS for fast server-to-server communication, SOAP for formal enterprise contracts, REST through IRIS for modern applications. The right choice depends on your consumers, your operational model, and whether you need synchronous responses or event-driven streaming.

For most teams, the pragmatic approach is a hybrid: keep OFS for internal back-end integration where both sides understand T24, and add IRIS-based REST APIs for customer-facing applications, mobile apps, and third-party integrations. This gives you the best of both worlds — the speed and simplicity of OFS where it works well, and the developer experience and documentation of REST where it matters most.

If event-driven streaming is what you need — Kafka integration, real-time event publishing, replacing file-based integration — that is covered in the companion article on Real-Time Event Architecture in T24.