GPLB technical requirements cover three things: TOTSCo’s Hub API (the message envelope, letterbox delivery, and directory lookups), a security framework chosen per endpoint, and the separate GPLB Switching Message Specification that defines the actual business payload. Every UK Communication Provider must implement all three before exchanging a single live switching message and has to connect its systems to TOTSCo’s switching Hub, or an approved alternative, before Ofcom’s compliance deadline. That connection is not a single task. It is a set of technical commitments your organisation has to build, test, and keep running.
Why GPLB Technical Requirements exist
Ofcom’s General Condition C7 requires business fixed voice and broadband switching to follow a gaining-provider-led process, the same principle behind residential One Touch Switching (OTS). Two organisations shaped what “compliant” actually means:
- The GPLB Steering Group, hosted by the Federation of Communication Services (FCS), wrote the business rules: which party sends which message, in what sequence, with what service level.
- TOTSCo, which already runs the Hub for residential OTS, published the technical specification: how that gets built, covering message structure, transport, authentication, and error handling.
A CP that only reads one of the two documents will build something that looks complete and still fails certification. That split matters because it changes who owns which risk. You can sequence every message correctly and still fail Hub testing over a malformed envelope or the wrong TLS version, or build a technically flawless integration against outdated routing values that breaks the real switching journey the moment it hits a live customer. Both documents deserve equal attention from your engineering team.
The Three Building Blocks of the TOTSCo GPLB API
Every technical requirement in the specification sits under one of three components: the message envelope, the letterbox API that moves messages, and the directory API that resolves where messages go. The diagram above shows how a single switching message moves through all three, from your own systems to the receiving provider. Understanding how they connect makes the rest of the specification far easier to implement correctly the first time.
Message Envelope and Routing Requirements
The envelope is the only part of a GPLB message the Hub actually reads. It wraps around your message body and carries the delivery information: source, destination, a routing identifier, and an optional audit data array. The Hub validates the envelope, routes it, and passes the body through untouched, so getting the envelope right matters more than getting the body right for basic delivery to succeed.
- Source and destination are each identified by a four-character RCPID, a code TOTSCo assigns your organisation during onboarding.
- Every source element needs a correlation ID, a reference your own system generates (up to 256 characters) so you can match a later reply back to the original request. GPLB doesn’t currently require this to be unique, but treating it like a UUID from day one avoids painful reconciliation problems once switching volumes grow.
- The routing identifier tells the Hub which delivery policy applies and what type of message you’re sending. It has to be one the Hub recognises and one mapped to your account; an unmapped value gets rejected before the message ever reaches a recipient.
Most early rejections during Hub testing trace back to a malformed or incomplete envelope rather than a business logic error, so getting this structure right on the first attempt saves weeks of back-and-forth.
Letterbox API: Transport, Limits, and Delivery
The letterbox API is how messages actually move between your systems and the Hub. It runs on a push model in both directions: you push a message to the Hub, and the Hub pushes it onward to the recipient. There’s no synchronous back-and-forth here, so an integration built around waiting for an immediate reply from the other provider won’t work.
The transport parameters are fixed by the specification, not configurable by you:
- Messages travel over HTTPS with TLS 1.3, on the current version of the connection protocol
- Individual messages are capped at 256KB
- The Hub enforces a platform-wide limit on how many messages it will accept per minute, across the whole industry, and throttles anything beyond that
Two confirmations matter here, and they’re not the same thing: an immediate response confirms only that the Hub accepted and validated the envelope, not that the message reached its destination, while a separate, later notification confirms whether delivery actually succeeded, carrying its own fault code if it didn’t.
Building monitoring around both is not optional if you want accurate visibility into your own switching pipeline. The Hub also checks that the security credentials presented on each call match the source identity declared in the envelope, and expects the same check running in reverse on your side, confirming that a message claiming to come from the Hub actually did. This bidirectional check is what stops a spoofed message being injected into either side of the switching journey, and it’s worth building explicit test cases around rather than assuming it works because the happy path succeeded once in a sandbox.
Directory API: Discovering active GPLB providers
Before sending a message, you need to know whether the intended recipient is registered, active, and actually supports GPLB rather than only OTS. The directory API answers exactly that question, returning the RCPID, trading name, supported processes, and current status for one provider or the full population.
- A provider can show as active for OTS, GPLB, both, or neither, and sending to a provider that isn’t active for GPLB returns a validation error before delivery is even attempted.
- TOTSCo recommends pulling the full directory list nightly, or weekly at the least, plus an on-demand lookup whenever a message arrives from a source you don’t already have cached. This is a caching problem, not a per-transaction lookup: calling the directory on every single switch adds unnecessary latency and puts avoidable load on shared infrastructure every CP depends on.
- Each entry also carries support contact fields, giving your team a standard way to point counterpart providers toward the right escalation channel for a given switch.
Design the caching layer to refresh on schedule automatically rather than relying on a manual process. A stale local directory is one of the more common causes of messages routed to a provider that’s since changed status, moved to a different MAP, or updated its endpoint configuration without every counterpart noticing in time.
Security Requirements: Five Valid Combinations
TOTSCo doesn’t mandate one security model. Five combinations of transport and application-level security are permitted, and you choose per endpoint, meaning different endpoints can run different mechanisms depending on what each system supports.
Each option carries a different operational cost. OAuth 2.0 tokens expire after one hour, so any integration relying on OAuth needs reliable, automated refresh logic, not a manual process someone remembers to run. API keys last six months and are capped at 256 characters; TOTSCo notifies you ahead of expiry, but renewing and redeploying across connected systems is your job. Mutual TLS certificates need at least a year of validity, and TOTSCo shares replacement certificates 30 days before expiry so the swap causes zero disruption, provided you act on that window. Ask “who on our team maintains this every month” before asking “which is technically strongest.”
Error Handling and Message Delivery Failures
The Hub validates every incoming message in a fixed sequence: security credentials first, then message size, then envelope structure, then individual fields, then whether source and destination are valid and active, and finally whether the routing identifier is recognised. A rejection can trace back to any point in that chain, so a generic error response is meaningless without checking the specific code that came with it.
The distinction that catches most engineering teams off guard is synchronous versus asynchronous failure:
- Synchronous errors mean the Hub never accepted the message at all. You know immediately, and the fix is usually on your side.
- Asynchronous delivery failures mean the Hub accepted the message but couldn’t deliver it to the recipient, for reasons ranging from an invalid route to a timeout on the receiving end. These arrive later, as a separate notification.
Retrying a rejected message the same way it was sent the first time produces the same rejection every time. Your error-handling logic needs to treat synchronous and asynchronous failures as two separate remediation paths, one you fix internally, the other you may need to chase with the other provider.
Testing, Onboarding, and Going Live
Registration starts with signing TOTSCo’s Hub User Agreement and providing your endpoint details for every connection point you intend to use. From there, TOTSCo runs multiple stages of testing before any GPLB connection goes live, and the number of stages depends on whether you connect directly or through a Managed Access Provider.
Two details commercial teams most often miss: TOTSCo commits to a minimum 30-day notice for any changes to the GPLB documents, so the specification your team builds against today isn’t guaranteed to be the final version at go-live, and ongoing monitoring of published updates is part of staying compliant, not a one-time task finished at launch. Peer-to-peer testing between counterpart CPs is part of certification too. You can implement the specification correctly in isolation and still hit friction the first time you exchange live-format messages with a real trading partner, so build extra time into your project plan for this stage rather than treating it as a formality after internal testing passes.
Build In-House or Work with a Managed Access Provider(MAP) ?
Every CP faces the same decision once the technical requirements are clear: build and operate this infrastructure internally, or hand the operational load to a Managed Access Provider. Building in-house means owning:
- Certificate lifecycle management and rotation
- Token refresh logic for OAuth-based endpoints
- Directory caching
- Error-handling logic across two separate failure classes
- Continuous alignment with a specification that changes on notice
None of that stops at go-live; it’s a standing operational commitment. A Full Management MAP takes on that ongoing weight so your engineering team can stay focused on the product itself rather than the plumbing underneath it.
The right answer depends less on your company’s size than on how much of this your engineering team already runs elsewhere. If you already operate certificate lifecycle management and API gateway infrastructure at scale, building in-house is a natural extension of existing capability. If you don’t, you’re usually better served treating GPLB compliance as a managed service from day one, rather than building that muscle from scratch under a regulatory deadline.