iMessage, WhatsApp, Telegram: Photon 2.0 brings AI agents together in a single API

Photon 2.0 connects AI agents to iMessage, WhatsApp, Telegram, SMS, email, and voice calls through a unified API, now available in public beta.

An AI agent capable of answering on iMessage, continuing a conversation on WhatsApp, or interacting with a customer by phone, without building a different infrastructure for each channel. With Photon 2.0, the developer-focused messaging platform expands its scope beyond the Apple ecosystem. This new version brings together iMessage, WhatsApp Business, Telegram, SMS, RCS, email, and voice calls behind a common API. It accompanies this extension with a rewrite of its iMessage engine, announced as 1.6 times faster, and new tools designed to monitor exchanges. A Single Infrastructure for Multiple Messaging Services

Photon began its development around iMessage, with the goal of allowing conversational agents to interact directly within Apple's Messages app.

The principle consisted of making assistants accessible from a communication tool already used on a daily basis, rather than asking users to install an additional application.

However, this initial approach remained centered on a single environment.

With Photon 2.0, developers can now connect their agents to iMessage, WhatsApp Business, Telegram, SMS, RCS, email, and phone calls from a single platform.

This centralization aims to limit the work required to support multiple services whose programming interfaces, message formats, and delivery mechanisms differ.

Even so, it does not transform these messaging services into a single network. Each channel retains its technical characteristics, features, and terms of use.

Photon acts as an intermediary layer responsible for managing part of this complexity and exposing common operations to the applications that use it. An iMessage Engine Rebuilt Around macOS

The new version is accompanied by a overhaul of the iMessage infrastructure, historically at the core of Photon.

The company explains that it encountered several difficulties during its development, including system kernel resource leaks, inconsistencies in the macOS state, and failures related to encryption.

These issues could not always be resolved by simply restarting the affected services.

Photon therefore rebuilt its iMessage engine and developed a layer for managing the state of macOS machines called Astrolabe.

This system serves to maintain the configuration and operation of the machines used to manage communications, particularly when a service encounters a failure.

According to Photon's internal measurements, the new engine is approximately 1.6 times faster than the previous one, with an announced latency of around 100 milliseconds.

This value pertains to measurements taken on its infrastructure and does not constitute a guaranteed end-to-end delivery time across all networks and devices.

Astrolabe had already been the subject of technical publications dedicated to managing macOS machines. Three Objects to Manage All Conversations

The unification of messaging services relies on a new API organization structured around three elements: Users, Spaces, and Messages.

A User represents a reachable identity on a given platform. It can be a phone number, an account, or another identifier associated with a channel.

A Space corresponds to the environment in which the conversation takes place: a one-on-one exchange, a group, or a discussion thread.

A Message represents the content exchanged, whether it be text, media, or interactions such as reactions.

This structure aims to maintain a consistent organization even when messaging services operate differently.

A developer can thus create a user, open a conversation, and then send a message using similar operations from one platform to another.

Photon nevertheless notes that a user identified on WhatsApp is not automatically considered the same person on Telegram or iMessage.

Likewise, available features vary by channel. Reactions, attachments, or certain types of replies are not necessarily supported everywhere. A Dashboard to Identify Delivery Issues

Photon 2.0 also introduces a reorganized dashboard to facilitate service monitoring.

In the case of iMessage, developers can view the status of Apple accounts, the health of Photon services, the availability of SMS and MMS relays, or the identity used for outbound messages.

The interface also allows checking call configurations.

This evolution particularly addresses a difficulty encountered with messaging infrastructures: a service can appear available even though part of its functions no longer works properly.

An active Apple account does not guarantee, for example, that the SMS relay is functioning or that new conversations are originating from the expected number.

The dashboard therefore seeks to make these intermediate states visible rather than summarizing the entire system into a simple availability indicator.

Technically, the interface was rebuilt with React and Vite, on a distributed serverless frontend architecture. Tracking a Message After Its Acceptance by the API

Photon also strengthens the observability features of its infrastructure.

When a developer sends a request, an HTTP `202 Accepted` response means that the server accepted it. It does not guarantee that the message actually reached its recipient.

Between these two steps, several services intervene, and different errors can occur.

Photon 2.0 allows viewing API logs, request details, and events associated with delivery.

The platform supports OpenTelemetry-compatible traces in order to track the various operations involved in processing a message.

Developers can also examine transmission attempts via webhook and WebSocket, as well as their results.

For investigations requiring more specific queries, Photon offers a SQL API based on ClickHouse.

These tools notably allow searching at which step an event failed, without having to manually reconstruct information scattered across multiple services. Voice Calls Join Conversational Agents

The expansion of Photon does not solely concern written messages.

The platform now supports inbound and outbound calls using the SIP protocol, which is used in many IP telephony