An API is a promise about behaviour. Most outages are broken promises.

TM Forum Open APIs are the telecommunications industry's standard interface specifications, maintained by the TM Forum and covering domains such as product catalog, product ordering and service ordering. Salesforce Communications Cloud conforms to them, and its Enterprise Product Catalog is certified against the TM Forum Information Framework, the industry's standard information model. The practical benefit is that both sides of an integration can build to a published shape instead of negotiating a bespoke one, which reduces rework and customisation, shortens the conversation with downstream vendors who also implement the standard, and keeps replacing a vendor a bounded change rather than a second transformation programme.

No, and this is the most useful thing to understand about standards. Conformance governs the structural contract — the shape of the request and response. It says nothing about behaviour: whether an endpoint is idempotent, how long it blocks, what its error taxonomy looks like, which errors are worth retrying, whether state changes are published as events, or how anyone traces a failure across systems. Those are the properties that determine whether an integration survives a bad day, and they have to be specified separately. We agree them per interface against a nine-point contract checklist alongside the structural specification.

Idempotency, designed into the contract rather than added later. Each request carries a key that lets the receiving system recognise a repeat and return the original result instead of performing the action again, and the contract states how long that key is honoured. Without it, a timeout against a slow downstream system produces a retry that becomes a second activation, a second charge or a second engineer visit. Because it only manifests under load it looks intermittent and is extremely hard to diagnose after the fact, so we verify idempotency explicitly under real concurrency rather than in functional testing, which will not find it.

It depends on the size and volatility of the estate, and we would rather tell you it is unnecessary than sell you the larger answer. API-led connectivity — system APIs over the legacy estate, process APIs orchestrating them, experience APIs per channel — earns its place when several systems must be reached for a single business operation, when the estate will change and you want consumers insulated from that, or when multiple parts of the business need the same underlying data. On a small, stable estate with few consumers, direct integration is simpler, cheaper and easier to diagnose. We assess which you actually have during the inventory step.

Asynchronously, in most cases. Service activation, provisioning and engineer visits legitimately take minutes to days, and modelling them as synchronous request-response means callers block and time out on operations that are succeeding — then retry them, which is where duplicate work comes from. The usual pattern is an accepted-and-acknowledged response followed by events or callbacks as state changes, with polling available as a fallback for consumers that cannot receive callbacks. That design also needs replay and late-arrival handling and idempotent consumer-side processing, because events do arrive twice and occasionally out of order.

Decide the strategy before the first consumer integrates, because retrofitting versioning to a live API is considerably harder. The essentials are a stated way of expressing a version, a defined support window for older versions, a clear distinction between additive changes that do not break consumers and breaking changes that do, and a deprecation process with real notice. Without this, in practice there is only ever one version, every consumer has to move simultaneously, and the rational response is to stop changing the API at all — which means the platform ossifies around its earliest design mistakes.

The integration page answers the architecture question: which systems connect to Communications Cloud, what data moves in which direction, in what sequence, and who owns the failure. This page answers the engineering question underneath it: how each of those interfaces is specified, secured, versioned, made safe to retry and made observable. If you are deciding what to connect and in what order, start on the integration page. If you are deciding how the endpoints themselves should behave and be operated, this is the right one.