CityFibre Provisioning API - NICC ALA (2.30)

Download OpenAPI specification:Download

Customer API Queries: customer-api-queries@cityfibre.com URL: https://www.cityfibre.com License: Apache 2.0 Terms of Service

Introduction

This API is a subset of NICC ALA standards ND1649 and ND1651, available from https://www.niccstandards.org.uk/publications/

For clarity, the SOAP envelope is omitted from the remainder of the documentation. It should be noted that this is just SOAP delivery of XML messages, and is not a "web service" with WSDL.

In NICC terminology, the Active Network Operator who provides the service is the "seller", and the Service Provider who consumes the service is the "buyer".

Custom attributes are added using the XML namespace URL http://www.cityfibre.com/ala/ext1

Messages are exchanged using SOAP exchanges over HTTPS POST, where the request is in the POST body and the response is in the HTTP response body. As per ND1651 section 14.2, messages are encapsulated in a SOAP envelope using Document/Literal style following WS-Basic Profile 1.0.

notifyOfOrderStatus messages are HTTPS POSTed to the buyer when available, at a pre-agreed callback URL.

The schema can be located here, with examples of the various messages located in the examples directory of this documentation pack. You can also find more detailed reading and examples in “Order Error Handling in ND1651 API Testing Approach” document which can also be found in this directory along with the New ISP Onboarding Test Scenario Verification.xlsx

An example of SOAP usage can be seen below:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <!--  Content goes here -->
    </soap:Body>
</soap:Envelope>

Authentication

Authentication is by means of HTTPS client certificate. It is also restricted to pre-agreed source IP addresses.

Certificate

Security Scheme Type: mutualTLS

Network and Firewall Configuration

Cityfibre provides two fixed-address API endpoints for redundancy:

api-gw1.cityfibre.com 52.51.45.11 (IPv6: 2a05:d018:9a3:b500::100)

api-gw2.cityfibre.com 52.58.75.78 (IPv6: 2a05:d014:b31:f200::100)

Messages may be POSTed to either of these. For convenience there is also a round-robin DNS entry: api-gw.cityfibre.com (resolves to both addresses)

Required firewall configuration is as follows.

(1) For connectivity please refer to Customer API Connectivity

Data should be posted with Content-Type: text/xml. No SOAP-Action: header is required and it will be ignored if provided. All message types go to the same endpoint.

(2) For connections from Cityfibre to buyer: buyer must allow HTTPS inbound connections to buyer's systems from IP addresses 34.240.45.9 and 52.17.98.120, to whichever port their system accepts inbound connections on.

(If the buyer system allows IPv6 connectivity, then the source addresses will be from ranges 2a05:d018:9a3:b500::/56 and 2a05:d014:b31:f200::/56)

FTTP Process Overview

Customer and site information required for a Business Property

On creating an order, the Buyer must include as much information as possible about a site where Property Classification is Business or Other to ensure a successful installation. On creating an order, where necessary, a wayleave has been obtained, the install scope is under 15m externally and 10m internally on the ground floor, and two power sockets are available within 1m of the preferred location.

Name: Name of person available on site on the day of installation who can provide internal access and has the authority to specify where the Optical Network Termination box will be located.

Email: Email address of the site contact specified above.

Phone number: Contact telephone number of the site contact for use on day of install.

Access Restrictions: Our install engineer will see what you enter here. Please advise things like: where can our van be safely parked, can you tell us alternative contact numbers for a keyholder other than the one above, for businesses, if the name above the door does not match our records; anything we need to be aware of on the day to achieve a successful entry.

If you know the preferred Optical Network Termination box location, please tell us.

Hazard Advice: If this is a commercial building built before 2000, please tell us where to find the asbestos register. If the building is not made of standard brick construction, please advise. If there is anything unusual, please tell us; a driveway laid with bespoke resin is just one example.

Project reference

Project references <cfh:projectReference> can be used to identify an order as being included in a particular project. A project reference, along with parameters of the project, will be pre-agreed between the Seller and the Buyer under a Formal Project Agreement. Parameters of the project will include a project name, start and end date, and any specific customer journey requirements.

If an invalid project reference is sent, or the project reference is sent outside of the start and end dates of the project, then the order will be rejected, and a 511 error code will be returned.

New Install

Availability Check

Query Address Search

To check the availability on a given location. The buyer should send a request containing either a postcode or a UPRN.

The seller is then going to respond with detailed information about the queried location. If the buyer queried using a UPRN, the response will contain only one location. On a postcode request, the seller might respond with multiple locations that match the given postcode.

The location details include among other fields:

UPRN
RFS (Ready For Service) status
Cabinet Release Date
LOC (Limit Of Construction) Codes
Whether the order will be a preorder

LOC reasons are flags which indicate known issues with this property. If there are multiple flags for a location they will be separated by spaces.

An order can be accepted for any RFS_1, RFS_2, RFS_3 or RFS_4 property.

Furthermore, the seller can query products for a given location using the location’s UPRN.

Query Products for Location

The seller will then respond with a list of one or multiple available products (if any) along with information about the need for an appointment (yes/no/maybe). The response will be one of the below listed types:

Appointment

The buyer can query appointment availability, reserve an appointment and include the reservation key in the order request.

If this is not done, the order will go into a waiting state and not progress, the buyer will need to reserve an appointment and then amend the order to include the appointment reservation key before the order can complete.

Query Availability

Query Appointment Availability

The buyer can check the appointment availability by providing a UPRN and a product to the seller.

Then the seller may respond with an ‘Accepted’ response along with the available appointment slots.

Or if for some reason an appointment is not possible to book, the seller will respond with a ‘Rejected’ response and with the reason why there is no appointment availability for the given data.

Reserve

Reserve Appointment

In order to reserve an appointment, the buyer should provide the UPRN, product and the appointment slot that they desire to the seller.

The seller can then reply with a successful response if such appointment can be booked along with the appointment details and a reservation key.

Or with a rejected response if there was any issue with booking the appointment along with the reason why such thing is not possible.

Order Submission

The order is created using an orderRequest message containing an <alaNewInstall> element. The Service Provider can choose between PPPoE Intermediate Agent or Layer 2 DHCP Relay Agent for authentication. This is a legacy field and regardless of selection the Service Provider is able to provide services using either protocol. DHCP and PPPoE discovery frames are modified to insert circuit ID and remote ID to assist the Service Provider in authentication.

Create New Install Order

The Seller provides the ability to order services that are provisioned with VLAN 0 or VLAN 911. This is enabled the Service Provider passing a Line Profile specific to either VLAN 0 or VLAN 911. The available Line Profiles for buyers to choose from are described in Line Profiles.

The seller will then reply with an empty order response to acknowledge that the order request was received

Updates are returned in the form of notifyOfOrderStatus messages. The sequence of order states is as per ND1649 section 5.1:

Pending
Acknowledged (KCI1)
Committed (KCI2)
- ENNI Reserved
- Missed Appointment
- Warning
- Cabinet Slip
Completed or Rejected (KCI3)
- Rejected with Reason

Note: The ‘Cabinet Slip’ example refers to a case where:

buyer has booked an appointment for date D1, which is on or after the cabinet release date D0

but prior to service going live, the cabinet release date has slipped from D0 to D2, which is now after the appointment date

hence seller has been forced to rebook the original appointment

Pre Orders

CityFibre will accept pre orders for locations where the cabinet release date is in the future, where DR status is DR3 or below and RFS status is NOT_RFS_2

The buyer can query appointments and reserve appointments beyond the cabinet release date.

Orders placed as pre order will return a delay after KCI 2

210	Pre-Order Awaiting Cabinet Release

Should the cabinet release date slip, orders will be automatically reappointed and a new date provided post the new cabinet live date.

Regrades

The Buyer can move between the FFN products through an automated journey meaning there is no manual effort required as well as no down time for the end customer when moving between product.

The Buyer can specify an order is a Regrade using the newOrderType field, on an RFS_4 property.

The seller (CityFibre) will handle the cease of the existing service, KCI updates will be sent to the Buyer as well as an unsolicited cease request.

Regrade orders can be cancelled using Cancel an Order. Orders can also be amended (Line profile or Requested Date) on a regrade order.

Product Change – No Access Change

Product Regrading From	Product Regrading To
Residential FTTH Local Access 160Mpbs	Residential FTTH Local Access (1Gbps)
Residential FTTH Local Access (1Gbps)	Residential FTTH Local Access 160Mpbs
Residential FTTH National Access 160Mbps	Residential FTTH National Access (1Gbps)
Residential FTTH National Access (1Gbps)	Residential FTTH National Access 160Mbps

Product and Access Change

Product Regrading From	Product Regrading To
Residential FTTH Local Access 160Mpbs	Residential FTTH National Access (1Gbps)
Residential FTTH Local Access (1Gbps)	Residential FTTH National Access 160Mpbs
Residential FTTH National Access 160Mbps	Residential FTTH Local Access (1Gbps)
Residential FTTH National Access (1Gbps)	Residential FTTH Local Access 160Mbps
Residential FTTH Local Access 160Mpbs	Residential FTTH National Access 160Mbps
Residential FTTH Local Access (1Gbps)	Residential FTTH National Access (1Gbps)
Residential FTTH National Access 160Mbps	Residential FTTH National Access 160Mbps
Residential FTTH National Access (1Gbps)	Residential FTTH Local Access (1Gbps)

Buyer checks availability
- Property RFS Status is returned from Sellers Availability Check
- Property is not RFS_4 follow standard Order Journey detailed above
- Property is RFS_4 and has a cease, follow LP WLTO
- Property is RFS_4 and and has no cease, follow regrade flow
Buyer submits order.
- On creating an order, the buyer will pass the UPRN of the existing service along with the relevant order details including the product and profile. In addition, for a regrade the buyer will need to send a requested date with the new order instead of an appointment date.
- Orders placed on the current day will be processed at midnight of the following day.
- Order delayed if:
  - Buyer does not include Requested Date - Expires in 30 days
- Order rejected if:
  - Buyer order reference is missing or duplicate
  - Buyer order reference exceeds the maximum length (36 characters)
  - UPRN is missing or not numeric
  - Product is the same as active service
  - Product is non-FTTH product
  - Product not permitted for this account or location
  - Gross errors in service configuration (invalid attributes or values)
KCI.1 Order Acknowledged issued to Buyer
KCI.2 Order Committed issued to Buyer
Seller sends unsolicited cease to buyer
Amendments are checked and either everything is accepted or rejected
- Reject any amendment to product or UPRN
- Accept amendments to site info
- Accept amendments to Requested Date
- Accept amendments to service configuration (e.g. ENNI, SVLAN/CVLAN, line profile, PPPoE Agent-Remote-Id): check for gross errors
- Cancellation of auxillary services: OK
Cease is completed at midnight of the requested date. (Usually this happens at 00:00 and is complete by 2am).
Provision ONT
Seller sends KCI.3

Amending

The buyer may request to amend an order if it is still in early stages.

Amend Order

The seller can then accept or reject the amendment of the order

Furthermore, notifyOfOrderStatus requests will reflect the amendment request

Cancellation

It is possible for the buyer to request that an order be cancelled before it is completed. Orders may also be cancelled by the seller if it is no longer possible to progress an order.

Buyer Cancellation

The buyer may request to cancel the order if it is still in early stages.

Cancel Order

The seller will then reply with the status of the cancellation

This will also reflect the notifyOfOrderStatus requests

Seller Cancellation

The seller may cancel the order if it is no longer possible to proceed. The buyer will retrieve a notifyOfOrderStatus.

Modify

Once a service has gone live, changing the line profile or requesting a change of ENNI/VLAN is done by means of an orderRequest . This follows the same overall flow as a new install order, but it may jump straight from Pending to Completed.

Modify Order

The available profiles for buyers to choose from when modifying an order are shown below. We should note that the API call name should be included as part of the call:

Modify ENNI

When an order is placed, the seller is defining an ENNI for the order and will provide to the buyer a list of available ENNIs via the notifyOfOrderStatus request

Then the buyer can modify the ENNI by sending back one of the codes returned in the <cfh:nniIdentifiers> list.

Any further notifyOfOrderStatus requests will contain the new ENNI.

To modify the ENNI, the buyer should send a modify orderRequest

Modify Line Profile

In addition to changing the line profile, sellers also have the ability to modify the line profile of their active service. This can be achieved through the use of the orderRequest call. The process of modifying a line profile follows a similar flow to that of a new install order.

For the Buyer to initiate the modification of a line profile they can send the line profile in <cfh:lineProfile>.

Once the line profile modification is successfully processed, all subsequent notifyOfOrderStatus requests will contain the updated line profile information.

Cease

A cease order follows the same flow with an <alaCease> order.

Cease Order

The <alaCease> element might contain a <requestedDate> element. If it is absent, then the cease will take place immediately. Otherwise, it will occur at the timestamp provided.

The seller will then start sending notifyOfOrderStatusRequests similarly to the standard order flow:

Pending
Acknowledged
Committed
Completed

The buyer can also cancel the cease by sending a <cancelOrderRequest> before the <requestedDate> timestamp tha was provided in the <alaCease> request.

Also, the buyer might also modify the <requestedDate> by sending an <amendOrderRequest>.

Lastly if the contract terms provide for a cease notice period, but the <requestedDate> is less than that time in the future, then the service will be charged for the whole cease notice period.

FTTH Installation Process Diagrams

A visual representation of the FTTH installation process can be found in the FTTH Install process as documented below

Order contains: Product; URPN; Site info (contact info, access restrictions, hazards); appointment reservation key; optional service configuration; optional auxillary services
Reject order if:
- Buyer order reference is missing or duplicate
- Buyer order reference exceeds the maximum length (36 characters)
- UPRN is missing or not numeric
- Product is non-FTTH product
- Product not permitted for this account or location
- Auxillary services not recognised, or not permitted with this product, or not permitted for this account
- Gross errors in service configuration (invalid attributes or values)
- Property type not FTTH
- Property RFS_Status_GIS__c is not RFS_1 (or NOT_RFS_2 for preorder) - if there is an appointment this will have been checked
- Appointment reservation key (if provided) is for wrong UPRN or wrong product or has expired
If the order contains an appointment key: check it is for the correct UPRN, reserve it and add service ID to it. If reservation key has expired, scrub the appointment from the order
- If the property requires an Extended Install (LOC flags "WSD" or "SUR") then the KCI2 notification will include delay code 203 Survey underway, and a case is opened.
Check cabinet release date. If there is an appointment, and the CRD is later than the appointment, then cancel the appointment and notify of slip. If the cabinet is not yet ready for service, KCI2 includes delay code 210 "Waiting cabinet ready" and go back to Wait Cabinet Ready.
Check amendments and either accept everything or reject
- Reject any amendment to product or UPRN - All amendments to site info are acceptable
- Amendments to appointment: check new appointment is for correct UPRN, if so accept it (Note: does XML allow removal of appointment without creation of new one?)
- Amendments to service configuration (e.g. ENNI, SVLAN/CVLAN, line profile, PPPoE Agent-Remote-Id): check for gross errors
- Amendments to auxillary services: check new auxillary services are valid for this product/account
- Cancellation of auxillary services: OK
a. Buyer cancel received: set Service state to Cancelled. Cancel the appointment reservation (if any). Terminate.

b. Seller cancel: if the property is no longer serviceable, e.g. has gone to NOT_RFS_3. (Or should this raise a case instead?)
Perform network provisioning for selected ENNI/SVLAN/CVLAN. (If it fails we could raise a case, or just go into exception for now)
If the order does not have an appointment, send notify "delayed - waiting appointment" and go to Waiting appointment, otherwise proceed to issue job pack. If appointment date has passed, mark 'failed' and wait for reappointment
Wait for buyer to amend the order to add a new appointment or cancel. Timeout if no appointment received within 30 days.
Process amendments:
- Reject any amendment to product or UPRN
- All amendments to site info are acceptable
- Amendments to appointment: check new appointment is for correct UPRN, if so accept it
- Amendments to service configuration: check for gross errors.
- Amendments to auxillary services: check new auxillary services are valid for this product/account
- Cancellation of auxillary services: OK
Issue the job pack to the installation partner
Waiting for response from installation partner. (We may also receive interim updates/notes during this time; ) 3 possible flows
- If response is "success" go to Completed (WF0)
- Depending on warning code go back to waiting for new appointment
- Depending on warning code then open case, put in delay
- If cancellation is received, then cancel the job with installation partner
Process amendments
- Reject any amendment to product or UPRN
- Amendments to site info: relay to installation partner (i.e. update installation job)
- If change to appointment: cancel the job with installation partner, return to waiting for appointment (Note: does XML allow removal of appointment without creation of new one?)
- Amendments/cancellations to auxiliary services: either reject, or update the job pack with installation partner
Update network provisioning (ENNI/SVAN/CVLAN/PPPoE/Line Profile) while waiting for installation
Perform ONT provisioning while waiting for installation
Waiting for case. Case closed successfully, go to waiting for new appointment; case cancelled, cancel order. Or we can receive cancel from buyer.
Notify completion; include warning if result no CPE or speedcheck failed.

Gaining Provider Led Switches (GPLS)

This process is for when an end customer wants to move from one Buyer (Losing Provider) to another Buyer (Gaining Provider) on the Sellers network. In this scenario the end customer has contacted the Gaining Provider first to initiate a Gaining Provider Led Switch process.

As a key principle for Gaining Provider Led Switch Orders, any amendments to install and cease dates will be aligned to ensure a smooth transition for the end customer.

Placing Gaining Provider Led Switch Orders

When placing an order on a property with a RFS Status of RFS_4, the Buyer must specify whether this is a Gaining Provider Led Switch Order, using newOrderType field with a value of “Switch”, this will ensure the correct journey is applied to the order, with the subsequent lead times. This does not apply for properties that have a RFS Status of RFS_1, RFS_2 or RFS_3.

If the newOrderType is not specified on an RFS_4 order, and the Buyer owns the existing service at the property, then the order will be treated as a Regrade order.

Gaining Provider Led Switch orders will default to a non-appointed provision, unless Install Options requiring an engineer installation are requested, or an ONT swap is required.

Lead times (Customer Requested Dates and Install Appointments)

Gaining Provider Led Switch orders have a 10 business day lead time that covers the NOT+ (Notice of Termination Plus) required lead time for requested date, or appointment date if managed install (N.B. This will change when One Touch Switch launches)

Customer Requested Dates should be sent with a Date only, if a specific time is also sent, this will be aligned to midnight of the same day.

Gaining Provider Led Switch Order Process

End Customer / Gaining Provider checks availability of product(s)
- The Gaining Provider can query products for a given location using the location’s UPRN.
- The seller will then respond with a list of the available products (if any) along with information about the need for an appointment (yes/no/maybe).
Customer Requests Appointment Date if Managed Install is Required
- The Gaining Provider can check the appointment availability by providing a UPRN and a product to the seller.
- Then the seller may respond with an "Accepted" response along with the available appointment slots. If an appointment is not possible to book, the seller will respond with a "Rejected" response and with the reason why there is no appointment availability for the given data.
Customer Reserves Desired Appointment
- To reserve an appointment, the Gaining Provider should provide the UPRN, product and the appointment slot that they desire to the seller.
- The seller will reply with a successful response if such appointment can be booked along with the appointment details and a reservation key. Or with a rejected response if there was any issue with booking the appointment along with the reason for the rejection.
Gaining Provider submits the Order Request
- The order must be submitted with a newOrderType of "Switch" and either an Appointment Reservation Key for a Managed Install or a Customer Requested Date. Please ensure the correct lead times are applied, to ensure the order is not rejected.
Seller sends KCI Order "Pending" to Gaining Provider
Seller validates Order
- If the order request cannot be fulfilled the Seller will send a KCI "Rejected"
- Seller validates Reserved Appointment if one is provided
Plan & Manage Switch Request
- Seller creates "New Install Order" for Gaining Provider
- Seller creates the "Cease Order" on behalf of Losing Provider if there is no in-flight Cease Order.
- Seller links the Cease Order from the Losing Provider and the New Install Order from the Gaining Provider
- Where Seller identifies an In-flight Cease Order it will be aligned to New Install Order Requested Date
Seller creates Cease Order on behalf of Losing Provider
- Seller sends KCI "Unsolicited Cease Request" to Losing Provider
- Seller sends KCI Cease "Pending" to Losing Provider
- Seller sends KCI1 Cease "Acknowledged" to Losing Provider
- Seller sends KCI2 Cease "Committed" to Losing Provider
Seller sends KCI1 Order "Acknowledged" to Gaining Provider
Seller sends KCI2 Order "Committed" to Gaining Provider
Wait for "Switch" Date
- This will either be the Customer Requested Date or the Appointment Date for a Managed Install Order
Cease Losing Provider Service
Send KCI3 Cease "Completed" to Losing Provider
Provision Gaining Provider Service
If managed Install, wait for confirmation of installation for Managed Install journey
Send KCI3 Order "Completed” to Gaining Provider

Cease of Existing Services

The Seller will handle the cease of the existing service, on behalf of the Losing Provider, for Switch orders. KCI updates will be sent to both Gaining Provider for the New Install Order and the Losing Provider for the Unsolicited Cease Order. Where a Cease Order is already in flight, the requested date will be aligned to the Gaining Provider New Install Order requested date.

When an Unsolicited Cease is sent to a Losing Provider, it will state that it is the result of a Switch.

If the Gaining Provider cancels the Switch Order, then the Unsolicited Cease will be automatically cancelled. Where there was already a Cease Order in flight this will not be cancelled.

Unsolicited Ceases

Cancel Other (N.B. this functionality will be removed when One Touch Switch is launched.)

For Switch Orders, the Losing Provider can cancel an Unsolicited Cease using the Cancel Other reason codes for Switch Orders. The cancel other code will be sent to the Gaining Provider of the order.

The Losing Provider shall only be permitted to use Cancel Other in the following circumstances:

a) where Slamming has occurred b) at the Customer’s request, where the Gaining Provider has failed to cancel the request after being directed by the Customer to do so (“Failure to Cancel”) c) where the telephone line is, or will be, ceased during the Transfer Period (“Line Cease”) d) for other specified reasons not related to a Customer’s request to cancel a transfer, and agreed by the relevant industry forum and approved by Ofcom e) in such other circumstances as defined by Ofcom.

For an Unsolicited Cease resulting from a Switch Order, one of the following Cancel Other codes must be used by the Losing Provider.

Code	Description
9120	SP REQUESTED CANCEL OTHER - NO AUTHORISATION GIVEN TO TRANSFER
9150	SP REQUESTED CANCEL OTHER - CUSTOMER HAS NEVER BEEN CONTACTED
9160	SP REQUESTED CANCEL OTHER - DELIBERATE ATTEMPT TO MISLEAD
9170	SP REQUESTED CANCEL OTHER - PURCHASED A DIFFERENT PRODUCT/SERVICE

Amendments to Gaining Provider Led Switch Orders

Amendments to Customer Requested Date, Appointment Date and Service Configuration can be submitted by the Gaining Provider and will be accepted and actioned up to the PONR of the business day before the install.

As a key principle for Gaining Provider Led Switches, any amendments to install and cease dates will be aligned to ensure a smooth transition for the end customer.

Gaining Provider submits Amend Order Request
Seller Responds with Amendment Pending
Validate Amend Request
If the amend request cannot be fulfilled the Seller will send KCI "Amendment Rejected" to Gaining Provider
Seller Processes the Amend Request
Seller sends KCI "Amendment Accepted" to Gaining Provider
If the Switch Date has been amended the Seller will send KCI "Amendment Accepted" to Losing Provider with the new date

Working Line Takeovers (WLTO)

This process covers when an end customer is moving home, and the property they are moving in to already has an active service provisioned. In this scenario the end customer has contacted the Gaining Provider to request a new service.

Placing a Working Line Takeover Order

When placing an order on an RFS_4 property, the Buyer must specify whether this is a WLTO using newOrderType field, this will ensure the correct journey is applied to the order, with the subsequent lead times. This does not apply for RFS_1, RFS_2 or RFS_3.

If the newOrderType is not specified on an RFS_4 order, and the Buyer owns the existing service at the property, then it will be assumed as a Regrade order.

Working Line Takeover orders will default to a non-appointed provision, unless Install Options requiring an engineer installation are requested, or an ONT swap is required.

Lead times (Customer Requested Dates and Install Appointments)

Working Line Takeover orders have a 10 business day lead time that covers the NOT+ (Notice of Termination Plus) required lead time for requested date, or appointment date if managed install.

Working Line Takeover orders where the Gaining Provider is also the Losing provider, and owns the existing service = 2 days

Customer Requested Dates should be sent with a Date only, if a specific time is also sent, this will be aligned to midnight of the same day.

WLTO Order Process

End Customer / Gaining Provider checks availability of product(s)
- The Gaining Provider can query products for a given location using the location’s UPRN.
- The seller will then respond with a list of the available products (if any) along with information about the need for an appointment (yes/no/maybe).|
Customer Requests Appointment Date if Managed Install is Required
- The Gaining Provider can check the appointment availability by providing a UPRN and a product to the seller.
- Then the seller may respond with an "Accepted" response along with the available appointment slots. If an appointment is not possible to book, the seller will respond with a "Rejected" response and with the reason why there is no appointment availability for the given data.
Customer Reserves Desired Appointment
- To reserve an appointment, the Gaining Provider should provide the UPRN, product and the appointment slot that they desire to the seller.
- The seller will reply with a successful response if such appointment can be booked along with the appointment details and a reservation key. Or with a rejected response if there was any issue with booking the appointment along with the reason for the rejection.
Gaining Provider submits the Order Request
- The order will be submitted with a newOrderType of "WLTO" and either an Appointment Reservation Key for a Managed Install or a Customer Requested Date. Please ensure the correct lead times are applied, to ensure the order is not rejected.
Send KCI Order "Pending" to Gaining Provider
Validate Order
- If the order request cannot be fulfilled the Seller will send a KCI "Rejected"
- Seller validates Reserved Appointment if one is provided
Plan & Manage Switch Request
- Seller creates "WLTO Order" for Gaining Provider
- Seller creates the "Cease Order" on behalf of Losing Provider if there is no in-flight Cease Order.
- Seller links the Cease Order from the Losing Provider and the WLTO Order from the Gaining Provider
- Where Seller identifies an In-flight Cease Order it will be aligned to WLTO Order Requested Date
Seller creates Cease Order on behalf of Losing Provider
- Seller sends KCI "Unsolicited Cease Request" to Losing Provider
- Seller sends KCI Cease "Pending" to Losing Provider
- Seller sends KCI1 Cease "Acknowledged" to Losing Provider
- Seller sends KCI2 Cease "Committed" to Losing Provider
Seller sends KCI1 Order "Acknowledged" to Gaining Provider
Seller sends KCI2 Order "Committed" to Gaining Provider
Wait for "Cease Order" Date
- This will either be the Customer Requested Date or the Appointment for the managed install date of the “WLTO Order”, or the Requested Date of the Cease Order where the Losing Provider has taken control.
Cease Losing Provider Service
Send KCI3 “Cease Order” Complete to the Losing Provider
Provision Gaining Provider Service
If managed Install, wait for confirmation of installation for Managed Install journey
Send KCI3 Order "Completed” to Gaining Provide

Cease of Existing Services

The Seller will handle the cease of the existing service, on behalf of the Losing Provider, for WLTO Orders. KCI updates will be sent to both Gaining Provider for the WLTO Order and the Losing Provider for the Unsolicited Cease Order. Where a Cease Order is already in flight, this will be linked to the WLTO Order, and where the WLTO Order Requested Date is before the Cease Order Requested Date, the WLTO Requested Date will be aligned to the Cease Order Requested Date.

When an Unsolicited Cease is sent to a Losing Provider, it will state that this is the result of a WLTO Order.

Where the Gaining Provider cancels the WLTO Order, then the Unsolicited Cease Order will be automatically cancelled. Where there was already a Cease Order in flight this will not be cancelled.

Unsolicited Cease

For an Unsolicited Cease related to a Working Line Takeover Order, a Cancel Other code can be used by the Losing Provider

‘9190 SP REQUESTED CANCEL OTHER - END USER NOT MOVING’.

Amendments to Working Line Takeovers Orders

Amendments to Customer Requested Date, Appointment Date and Service Configuration can be submitted by the Gaining Provider and will be actioned up to the PONR of the business day before the install.

As a key principle for Working Line Takeover Orders, where any amendments to install and cease dates are requested, the Install date must be on or after the Cease Date. A Losing Provider can take control of the Cease Date by amending the requested date of the Unsolicited Cease Order. Once the Losing Provider has taken control of the of the WLTO Order, the Gaining provider can still amend the Service Configuration and the Requested Date. Only amendments to Requested Date where the date requested is after the Losing Providers Requested Cease Date will be accepted.

Amendments to Working Line Takeovers Orders by the Gaining Provider Process

N.B. This process only represents changes to the Requested Date or Appointment Date where the WLTO Order has a Managed Install. Service Configuration related Amendments will be accepted up to the PONR.

Gaining Provider submits Amend Order Request
Validate Amend Request
- If the amend request cannot be fulfilled the Seller will send KCI "Amendment Rejected" to Gaining Provider
Seller Responds with “Amend Requested Date / Amend Appointment Date” Pending
Where the Losing Provider “Has Control” of the WLTO Order Date
- If the Amended Requested Date is after the Requested Cease Date the Amended Requested Date / Appointment Date is Accepted “Amend Requested Date / Appointment Date Accepted”
- If the Amended Requested Date is before the Requested Cease Date the Amended Requested Date is Rejected “Amend Requested Date Rejected”
If the Losing Provider does not “Have Control”
- Amend the Requested Date of the Cease Order to the Gaining Provider Amended Requested Date
- Seller notifies the Losing Provider Requested Date Amended “GCP Amended Requested Date”
- Seller notifies the Gaining Provider “Amend Requested Date / Appointment Date Accepted”
If Managed Install and amended Appointment Date is after the PONR, Amend Request is rejected “Amend Appointment Date Rejected”

Amendments to Working Line Takeovers Orders by the Losing Provider Process

Losing Provider submits Amend Cease Order Request
Seller validates the Amend Request
- If the amend request cannot be fulfilled the Seller will send KCI "Amendment Rejected" to Losing Provider
Seller Responds with “Amend Requested Date” Pending
If the Amended Requested Date is before the WLTO Requested Date the Amended Requested Date is Accepted “Amend Requested Date / Appointment Date Accepted”
Where the Amended Requested Date is after the Requested WLTO Date
- If the WLTO Order is not Managed Install, the Amended Requested Date is Accepted “LCP Amended Requested Date”
- If the WLTO Order is Managed Install and after PONR, the Amended Requested Date is Rejected “Amend Requested Date Rejected” to Losing Provider
- If the WLTO Order is Managed Install and after PONR, delay WLTO Order and send Delay Reappoint notification “LCP Amended Requested Date” to Gaining Provider
- Manage Reappointment with Gaining Provider
Update Losing Provider Amended Requested Date
Notify Amend Requested Date Accepted
Losing Provider now “Has Control” for the WLTO Order Date

Remote Activation

RFS_3 properties are eligible for non-appointed remote activations. If the Buyer does not wish to include any auxiliary products (i.e. CPE Install), then a non-appointed activation can be ordered, for next working day onwards.

If the RFS_3 property requires an ONT Swap or CPE Install, then this will require an appointment, and the standard lead times will be applied.

ONT Swaps

If the product being ordered requires a higher bandwidth than the current ONT supports, then an engineer appointment maybe required to change the ONT installed at the property.

When querying for products at a property with an installed ONT(RFS_3 or RFS_4) we will perform a check of the ONT type that is currently installed against the products that are available to check if the products that are being returned will support the installed ONT type.

You can view whether an appointment is required by performing a Query Products for Location request. In the response you will be able to see whether an appointmentRequired is yes/maybe/no.

If the installed ONT type does not support the product you are querying then an appointment will be required and you will receive yes in the query products for location response.
If the installed ONT type does support the product you are querying then an appointment will not be required and you will receive maybe in the query products for location response.

If an order is placed against a property with an installed ONT and the product does not support the installed ONT type then the order will require an appointment otherwise it will be rejected.

Auto Compensation

Introduction

Ofcom introduced the Voluntary Code of Practice for an Automatic Compensation Scheme that enables Communications Providers to calculate and make automatic compensation payments to end customers where there has been a delay in the provision or repair of their service and where an appointment has been missed.

Key Principles

CPs will automatically get the updated and new KCI notifications when the functionality has been released.
Notifications will only be sent where there has been a SLA failure, no messages will be sent where fault or provision is success without any delay.
Missed appointment notifications will be sent when the appointment is NOT successfully completed immediately, or within the timescale defined previously.
An agreed set of reason codes will be used appropriately to define all non-CityFibre elements of the total delay. See Appendix A for the current version of Exclusion Reason Code set. Note that these have been aligned to Openreach’s reason codes, where applicable to CityFibre, to reduce complexity for CPs.
Missed appointment notifications will not be sent on “soft appointments”, and no missed appointment SLA will be payable for “soft appointments”
A soft appointment is an appointment that is not contractually confirmed and communicated to the CP.

Provision Missed Appointment Notification

Introduction

Provision Missed Appointment Notification is one of a number of related requirements that support CPs deliver accurate delay and missed appointment compensation for non-end customer failures, i.e. failures encountered that were not the end customers fault, and introduces additional KCI notifications to the CP with details of missed appointments and additional attributes for a late provision order.

Requirement Details

Currently the SLAs that are covered by CityFibre only cover the payment to CPs for any delay or missed appointments. They do not consider SLA or SLG payments for end customers.

This requirement only covers the technical changes to the API to support additional KCI notifications. Manual processes related to Auto Compensation Reporting from CityFibre will be covered separately but may be referenced below.

Scope

The scope covers:

Sending Missed Appointment Notifications to CPs when the appointment is missed, this notification will be sent immediately after an appointment is missed and before the provision is completed or cancelled.
Additional attributes included as part of Missed Appointment Notifications to enable the CP to accurately calculate compensation.

Missed Appointment Notification

CP will receive Missed Appointment Notification after an appointment is:
- Missed (either by CityFibre or by the end customer)
- Amended after 1pm the day before the start of appointment slot or inside appointment slot
- Cancelled after 1pm the day before the start of appointment slot or inside appointment slot
KCI 2.1 will contain the following information:
- Buyer Order reference number
- Seller Order Reference number
- Service Identifier
- Appointment Reservation Key
- Appointment date
- Appointment start time
- Appointment end time
- Seller Missed (Y | N)
- Amended (Y | N)
- Cancelled (Y | N)
- End User Missed (Y | N)
- End User Pre-agreed (Y | N)
- MBORC (Y | N)
Missed Appointment Notifications will be provided on or before the 9th calendar day after the appointment event where that event is either classified as missed, amended or cancelled and not at the completion of the order. Notifications will be sent out on a per order/service basis. There may be multiple Missed Appointment Notifications sent out for a single order (and repeat missed appointments are in scope and eligible for auto compensation). Additional attributes included with Missed Appointment Notifications:
- Missed and Amended
  - For Missed Appointment Notifications, the combination of amended/cancelled and end customer pre-agreed defines whether an appointment is late amended or late cancelled by CP or CityFibre.
  - If Seller Missed = Y, then the appointment was missed by CityFibre
  - If End User Missed = Y, then the appointment was missed by CP or End User
- End User Pre-agreed is determined by:
  - Set to Y when Amended = Y and CP amended the appointment late.
  - Set to Y when Cancelled = Y and CP cancelled the appointment late.
  - Set to Y when all other flags are set to N and an engineer visited the premises outside the appointment slot and that visit was agreed with the end customer.
  - For all other scenarios End User Pre-agreed will equal N.
- Cancelled
  - Set to Y if the order is cancelled by CityFibre or the CP.
- Following combinations indicate compensation due:
  - Seller Missed = Y and MBORC = N
  - Amended = Y and End User Pre-agreed = N
  - Cancelled = Y and End User Pre-agreed = N

Late Provision Notification

Introduction

Late Provision Notification is one of a number of related requirements that support CPs deliver accurate delay and missed appointment compensation for non-end customer failures, i.e. failures encountered that were not the end customers fault, and introduces additional KCI notifications to the CP with details of missed appointments and additional attributes for a late provision order.

Requirement Details

Currently the SLAs that are covered by CityFibre only cover the payment to CPs for any delay or missed appointments. They do not consider SLA or SLG payments for end customers.

Scope

The scope covers:

Sending Late Provision Notification to CPs if the SLA has been breached. This notification is sent after a failed order has completed.
This is an additional notification sent where an order has failed the SLA.

Late Provision Notification

CP will receive Late Provision Notification after completion of a failed SLA order (completion or cancellation)
- Late Provision Notification will contain the following information:
  - Buyer Order reference number
  - Seller Order Reference number
  - Service Identifier
  - Total number of calendar days the order is in delay.
  - Number of calendar days the order is in delay that CityFibre is responsible for.
  - Number of calendar days the order is in delay that CityFibre is not responsible for.
  - 0 or more Exclusion Reasons, Exclusion Start date, Exclusion End date, and the number of days the order is in delay under that exclusion reason that CityFibre is not responsible for.
Total Number of calendar days the order is in delay is calculated based on the latest Pre-Agreed appointment date where that appointment hasn’t been amended after 1pm the day before the appointment (i.e. late amended).
Late Provision Notification message will be generated on or after the 15th calendar day after the generation of the KCI3 / KCI-Cancel Notification.
Expectation is that Late Provision Notifications should be provided to the CP by 15th calendar day after the KCI3 / KCI-Cancel and all Late Provision Notifications will be provided by 21st calendar day. Notifications will be sent out on a per order/service basis.

MBORC – Rules for Auto Compensation

A MBORC (Matters Beyond our Reasonable Control) event can be declared for both Provision and Repair Appointments based on local constraints.

The existing MBORC process will be reused for Auto Compensation.

Type of MBORC on System	Auto Compensation Late Provision SLA payable for delays on order (Provision)	Auto Compensation Late Repair SLA payable for delays on faults (Repair)	Auto Compensation Missed appointment SLA payable for missed appointments
Missed Appointment-Provision	Y	NA	N
Missed Appointment-Repair	NA	Y	N

N = Auto Compensation does not apply (i.e. excluded due to MBORC)

Y = Auto Compensation applies (i.e. MBORC exclusion is not applicable)

NA = Not Applicable - MBORC not relevant

Exclusion Reason Codes

Exclusion Reason Code	Wording for Industry presentation	Sample Scenarios
RC001	End Customer/Communications Provider requested cancellation of job (Due to late cancellation this needed to be provided and then ceased)	Order has been cancelled late, CityFibre systems are unable to cancel and must either complete the Order Journey or cancel the order after the missed appointment.
RC002	End Customer (or agent) caused damage to equipment or wiring
RC003	End Customer access issues	No access to end customer premises No suitable person available at end customer premises End customer created access issues Wayleave refused No Access Possible Hazard
RC010	Not total loss of Service
RC012	MBORC
RC014	Communications Providers access or site details unavailable or incorrect	When the CP wants to manage the access and their details are unavailable or incorrect
RC016	Temporary Service has been provided but additional work was required to provide permanent service.	All services have been restored; however, further quality work is required (the order/fault may remain open until this is completed)
RC036	Delivery date amended to a new date by the CP (prior to the original date), or the CP did not choose the earliest available date offered	Earliest available date not originally chosen, or CP requested date change
RC037	CP did not choose the earliest available date offered	Earliest available date not originally chosen
RC043a	Site Unsafe	Hazard End User Issue

Next Best Action

Should an FTTP order be delayed, a delay code will be provided along with a recommended next best action to take.

For example a delay code of 220 may be returned for ‘Pet Behaviour’, with the recommended Next Best Action message "Before reappointing, please engage customer and mitigate on-site pet animal hazard. Reappoint with the customer after completion of contact and agreed action."

For an example of a message containing a next best action, see the notify of order status webhooks

Ethernet Process Overview

Ethernet Availability Check

Ethernet services for businesses differ from FTTP as they offer symmetric committed information rates and transparently deliver packets without the PPPoE/DHCP authentication used in FTTP. These services may be delivered over the Full Fibre or Metro networks.

Query Address Search

The buyer sends the seller a request containing either a postcode or a UPRN.

The seller then responds with detailed information about the queried location. If the buyer queried using a UPRN, the response will contain only one location. On a postcode request, the seller might respond with multiple locations that match the given postcode.

The seller then queries the products available at a given location using the location’s UPRN as the address key.

Query Products for Location

The seller will then respond with the following information. One or multiple products if available at that location, whether an appointment is required (“maybe”) and the indicative distance in meters from the centre of the postcode submitted to the nearest CityFibre network asset (for Metro Ethernet results).

Ethernet Products can be seen in the Products Reference

Installation Statuses

Green:

Build costs are likely to be within the standard installation charge.

Amber:

There are likely to be some additional construction charges in addition to the standard installation fee. There are likely to be additional checks needed before your order is processed and additional build time if your order is accepted.

Red:

There are likely to be significant additional construction charges on top of the standard installation fee. There are likely to be additional checks needed before your order is processed and additional build time if your order is accepted.

Customer API Connectivity

API Environment Introduction

CityFibre have three API environments: CFSIT, CFStaging and Production

Pre-Production

CFSIT is considered a development sandbox for customer system integration testing. This environment will allow customers to:

query availability
query products for locations
query appointments
reserve appointments
create an order
perform in-flight changes e.g. appointments and line profile amendments
Test Post codes will be provided to ensure that testing can be performed by customers in advance and CityFibre will ensure that there are sufficient properties to cover the various test scenarios.

CFStaging is the environment where customers and CityFibre can collaboratively complete end-to-end functional verification before enabling access in Production. Test Scenarios are included in the document named: New ISP Onboarding Test Scenario Verification.xlsx

Orders can be progressed using an internal tool, where access will be provided to the ISP by CityFibre. (Note this tool is not available in Production)
The ISP will have to complete the test either collaboratively with CityFibre, or in their own time and return the competed document noted above with all mandatory tests completed.
Test Post codes will be provided to ensure that testing can be performed by customers in advance and CityFibre will ensure that there are sufficient properties to cover the various test scenarios.

Production

Live environment

API Setup Process

The process starts with access being provided to the pre-production environments, once the customer has provided the information specified below.

Customers can use CFSIT as a sandbox during their development for testing purposes.

When the customer is ready, access to CFStaging will be given in order to complete the end-to-end verification. A joint session can be held to verify the scenarios listed below, or the customer can complete the scenarios in isolation. The completed Test Scenario document should be returned to CityFibre detailing the completed mandatory tests. The verification is designed to ensure that the customer is able to complete all the necessary API calls systematically.

Typical Process Flow

Customer provides technical details for pre-production and production environments
CityFibre configure pre-production environments
Customer use CSFIT for development
Verification of end-to-end verification in CFStaging
CityFibre configure production environment
Customer use production for live availability and orders

Required Information

In order for CityFibre to set up the environments for the customer, the following detail for Pre-Production and Production is required.

Client SSL certificate for validating authentication

This needs to be a valid certificate issued by a recognised Certification Authority and the pem file sent to CityFibre as a text file.
This can be a simple Email Identity Verification certificate from a vendor like Comodo (e.g. https://comodosslstore.com/email-identity/email-certificate)
CityFibre will need a separate one for Pre-Production (i.e. one that covers both CFSIT and CFStaging) and one for Production.
The customer will have to ensure that the relevant certificate is included with all calls to the API.
CityFibre validate the Distinguished Name on the certificate matches what we’re expecting for the included buyer Identifier when the customer calls our API with the certificate.

A secure SOAP HTTP endpoint

This is for CityFibre to send the XML notifications to the customer.
This is the endpoint that we send all KCI notifications to.
A separate endpoint is required for each environment.

A list or range of IP addresses

Required for CityFibre to whitelist access for each environment’s API.

CityFibre will assign a Unique Buyer Identifier for each environment and provide this to the customer in advance. These must then be used for all API calls for the relevant environment.

Test Scenarios

The individual API calls are included in the document named New ISP Onboarding Test Verificaion.xlsx and cover the following End-to-end, in flight and in life scenarios:

Availability check to live service.
- The Customer will be provided with access to a tool that will enable them to progress an order through the stages to complete (separate documentation will be provided for this tool).
- The Customer will need to provide the KCI notifications in XML format.
In flight Amend (e.g. appointment or line profile amendment)
- The Customer will need to provide the Buyer or Seller reference and what the change was so that CityFibre can verify success.
Service Cease
- The Customer will need to provide the Buyer or Seller reference so that CityFibre can verify the cease order has been created.
In life Modify (e.g. line profile change)
- The Customer will need to provide the Buyer or Seller reference and what the change was so that CityFibre can verify success.

Reference

RFS Statuses

Code	Meaning	Description
NOT_RFS_0	Not in area	Not within an area being considered
NOT_RFS_1	City Selected / In Planning	In an area that is currently being or will be planned
NOT_RFS_2	Planning Complete / Under Construction	In an area that has been planned and/or construction is currently in progress
NOT_RFS_3	Unable to Pass Property (Hard LOC/OOS/Not Viable)	Passive network for Property will not be built
NOT_RFS_4	New Address	This is a new address and will not be built as wasn't planned
RFS_0	Property Passed - Soft LOC	Passive network to Property built - but cannot do installation
RFS_1	Property Passed	Passive network to Property built - ready for install
RFS_2	Connected Externally	Passive network to Property built - and Property garden dig complete
RFS_3	Connected Internally	Passive network to Property built - and Property home install complete
RFS_4	Active	Property fully cabled end to end (service may or may not be live)

LOC Codes

Type	LOC Codes	Description
Advisory	SUR	Survey Required
Advisory	WSD	Wayleave Shared Drive
Advisory	DTL	Drive Too Long
Soft	WAY	Wayleave Owner/Landlord
Soft	NIS	Not Immediately Serviceable (i.e. Premise will move to RFS_0)
Soft	AUD	Audit Required
Soft	WREF	Wayleave Refused
Soft	BP	Business Park
Soft	FCK	Feasibility Check Failed
Soft	MDU	MDU Pathway from Public Highway to Main Building Present
Temp	PRRD	Wayleave Private Road
Temp	ADRD	Wayleave Unadopted Road
Temp	RFB	Ready For Build
Temp	NOTDES	Not Designed
Temp	SSEC58	NRSWA Sec58/117 restrictions
Temp	MISC	No other LOC Scenario Applies
Temp	PIA	Physical Infrastructure Access
Hard	UEL	Uneconomic Length
Hard	UEST	Uneconomic Surface Type
Hard	SED	Uneconomic Special Engineering Difficulty
Hard	OOR	Out of Optical Range
Hard	OOS	Out of Scope (Planned but not being build)

Products

Note that product availability is determined by contract so not all products are available to all buyers.

The available products depend on the contract between the buyer and the seller.

Product availability to a location should always be checked via the Query Products for Location API call before placing an order.

FTTP Products

Ethernet Products

Code	Name
enni-tail-eth-100	Ethernet 100
enni-tail-eth-1000-flex	Ethernet 1000 Flex
enni-tail-eth-md1000	Ethernet 1000

Auxiliary Services

Code	Name	Description
CPEInst1	FTTR CPE Install	Customer Premises Equipment
ResBBU1	FTTR BBU Install	Battery Back Up
ResVOIP1	FTTR VOIP Install	Voice over Internet Protocol

Line Profiles

The Seller provides the ability to order services that are provisioned with VLAN 0 or VLAN 911.

Line profiles will be returned in the query products response. The line profiles returned will be those eligible for the product selected, and the Buyer.

The allowed values depend on the contract between the buyer and the seller.

Residential FTTP and Business FTTP Standard

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
110	110	30	15	G110/15/30	Tagged (Vlan 0) [AF+EF]
110	110	30	15	G110/15/30-Vl911	Tagged (Vlan 911) [AF+EF]
110	110	30	15	G110/110/30/15-U	Untagged
220	220	40	15	G220/15/40	Tagged (Vlan 0) [AF+EF]
220	220	40	15	G220/15/40-Vl911	Tagged (Vlan 911) [AF+EF]
220	220	40	15	G220/220/40/15-U	Untagged
550	550	50	25	G550/25/50	Tagged (Vlan 0) [AF+EF]
550	550	50	25	G550/25/50-Vl911	Tagged (Vlan 911) [AF+EF]
550	550	50	25	G550/550/50/25-U	Untagged
1000	1000	70	35	G1000/35/70	Tagged (Vlan 0) [AF+EF]
1000	1000	70	35	G1000/35/70-Vl911	Tagged (Vlan 911) [AF+EF]
1000	1000	70	35	G1000/1000/70/35-U	Untagged
1000	1000	40	20	G1000/20/40	Tagged (Vlan 0) [AF+EF]
1000	1000	40	20	G1000/20/40-Vl911	Tagged (Vlan 911) [AF+EF]
1000	1000	40	20	G1000/1000/40/20-U	Untagged
0.064	0.064	0.064	0.064	G64K/64K	Tagged (Vlan 0) [AF+EF]
0.064	0.064	0.064	0.064	G64K/64K-Vl911	Tagged (Vlan 911) [AF+EF]
0.064	0.064	0.064	0.064	G64K/64K/64K/64K-U	Untagged

Residential FTTP 160

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
160	160	10	10	G160/10/10	Tagged (Vlan 0) [AF+EF]
160	160	10	10	G160/10/10-Vl911	Tagged (Vlan 911) [AF+EF]
110	110	10	10	G110/10/10	Tagged (Vlan 0) [AF+EF]
110	110	10	10	G110/10/10-Vl911	Tagged (Vlan 911) [AF+EF]
90	90	10	10	G90/10/10	Tagged (Vlan 0) [AF+EF]
90	90	10	10	G90/10/10-Vl911	Tagged (Vlan 911) [AF+EF]
45	45	10	10	G45/10/10	Tagged (Vlan 0) [AF+EF]
45	45	10	10	G45/10/10-Vl911	Tagged (Vlan 911) [AF+EF]

Business FTTP

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
1000	1000	100	40	BF1000/40/100	Tagged (Vlan 0) [AF+EF]
1000	1000	100	40	BF1000/40/100-Vl911	Tagged (Vlan 911) [AF+EF]

Business FTTP 160

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
160	160	10	10	G160/10/10	Tagged (Vlan 0) [AF+EF]
160	160	10	10	G160/10/10-Vl911	Tagged (Vlan 911) [AF+EF]

Layer 2 FTTP 2.5Gbps Business and Layer 2 FTTP 2.5Gbps Residential

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
2500	2500	70	35	G2500/35/70-Vl911	Tagged (Vlan 911) [AF+EF]
2500	2500	70	35	G2500/35/70	Tagged (Vlan 0) [AF+EF]
1800	1800	70	35	G1800/35/70-Vl911	Tagged (Vlan 911) [AF+EF]
1800	1800	70	35	G1800/35/70	Tagged (Vlan 0) [AF+EF]
1200	1200	70	35	G1200/35/70-Vl911	Tagged (Vlan 911) [AF+EF]
1200	1200	70	35	G1200/35/70	Tagged (Vlan 0) [AF+EF]

Layer 2 FTTP 1.2Gbps Business and Layer 2 FTTP 1.2Gbps Residential

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
1200	1200	70	35	G1200/35/70-Vl911	Tagged (Vlan 911) [AF+EF]
1200	1200	70	35	G1200/35/70	Tagged (Vlan 0) [AF+EF]

Layer 2 FTTP 2.0Gbps Business and Layer 2 FTTP 2.0Gbps Residential

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
2000	1000	70	35	G2000/35/70A-Vl911	Tagged (Vlan 911) [AF+EF]
2000	1000	70	35	G2000/35/70A	Tagged (Vlan 0) [AF+EF]
1800	1000	70	35	G1800/35/70A-Vl911	Tagged (Vlan 911) [AF+EF]
1800	1000	70	35	G1800/35/70A	Tagged (Vlan 0) [AF+EF]
1200	1000	70	35	G1200/35/70A-Vl911	Tagged (Vlan 911) [AF+EF]
1200	1000	70	35	G1200/35/70A	Tagged (Vlan 0) [AF+EF]

Layer 2 FTTP 1.2Gbps Business Asymmetric and Layer 2 FTTP 1.2Gbps Asymmetric

PIR (Mbps) Downstream	PIR (Mbps) Upstream	CIR (Mbps) Downstream	CIR (Mbps) Upstream	API Call name	Service
1200	1000	70	35	G1200/35/70A-Vl911	Tagged (Vlan 911) [AF+EF]
1200	1000	70	35	G1200/35/70A	Tagged (Vlan 0) [AF+EF]

Installation Process

CityFibre categorise all premises as either a Standard, Extended Standard or Non-Standard Installation. Rates and appointment SLAs for these types of installation are as per the Service Provider agreement.

Standard Installation

To identify a premise as a Standard Installation the Service Provider should assume: PRE-RFS: That any UPRN without any value in the LOC Field will be a Standard Installation POST-RFS: That any UPRN with RFS code RFS_1 and no value in the LOC field is a Standard Installation

Extended Standard Installation

To identify a premise as an Extended Standard Installation the Service Provider should assume: PRE-RFS: That any UPRN with a value of SUR or WSD in the LOC Field will be an Extended Standard Installation POST-RFS: That any UPRN with RFS code RFS_1 and a value of SUR or WSD value in the LOC field is an Extended Standard Installation

Non-Standard Installation

To identify a premise as a Non-Standard Installation the Service Provider should assume: PRE-RFS: That any UPRN with a value of MDU or UEL or UST in the LOC Field will be a Non-Standard Installation POST-RFS: That any UPRN with RFS code RFS_1 and a value of MDU or UEL or UST value in the LOC field is a Non-Standard Installation

Status and Error Codes

The following status codes are defined. This list may be extended, and all unknown codes should be treated as "other reason". The text displayed below is not the same as the text returned by the API. These are just descriptions of that the codes mean. For testing/development the buyer should use the codes to identify errors/warnings etc. The API messages may change at any time without warning but the codes will retain their meaning.

informationCode

None currently defined

delayCode

Code	Description
200	Awaiting buyer action
201	Buyer-initiated exception
202	Seller checking feasibility
203	Seller manual provisioning or Survey underway
204	Resolving network issue
205	Select ENNI/VLAN
206	Select Requested Date
210	Pre-Order Awaiting Cabinet Release
211	Access gained - Unable to gain approval for network delivery install route from customer
212	Access gained - PTW / Wayleave not obtained as customer requires permission
213	Wayleave Permission Not Agreed
214	Shared Drive Not Agreed
215	Landlord Not Agreed
216	Route Approver Not Present
217	Internal Route Not Agreed
218	External Route Not Agreed
219	Customer Behaviour
220	Pet Behaviour
221	Environment Unsuitable
222	Scaffolding
223	Asbestos
224	Customer Not In
225	Customer Ill
226	OTD due to Illness
227	Already Rescheduled
228	Would Like to Reschedule
229	OTD on call ahead by Engineer - No Property Visit Made
231	No access - Premises Unoccupied or Vacant
232	Already Have Fibre
233	Never Ordered
234	Need More Info from ISP
235	Address Incorrect
236	Unable to locate Building
238	Winback
239	Cancelled Already
240	Changed My Mind
241	No Knowledge of Appointment
242	Tree Line of Sight
243	Flat Roof
244	Extended Install Encountered
245	Non Standard Install Encountered
246	Revisit Required
247	Matters Beyond Resonable Control
248	Failed to Attend
249	Incomplete Network
250	No Infrastructure present
251	Openreach D Pole
252	No Capacity at SN/ASN Available
253	Toby Move required
254	Line of Sight issue
255	Blockage - Gel Wrap
256	Blockage - Lead In (Openreach)
257	Unable to blow fibre between the Secondary Node cab and Toby
258	No Light (SN/PN)
259	No Light (ASN)
260	Light reading out of scope (High or Low optical signal)
261	ONT Issue
262	CPR Dry Install Complete
263	CPR Dry Install Not Complete
264	No dial tone
265	Additional Assistance
266	CF Solution Required
267	Occupancy change
268	Incorrect Property Type
269	Line of Sight Not Rectifiable
270	ONT Power Issue
299	Other reason

warningCode or cancellationReasonCode

Code	Description
110	Buyer Appointment Amendment
111	Seller Appointment Amendment
112	Customer Cancellation - Seller To Reappoint
300	No longer required
301	Failed to perform cabinet patch
302	Failed to install property drop fibre
303	Failed to activate service
304	Order timed out at seller
305	Unable to obtain wayleave or survey failed
306	Site unsafe
307	No access
308	No access - Premises Unoccupied or Vacant
309	Sales query (customer disagrees with captured details of order or has changed their mind)
310	Unforeseen circumstance (which would be prohibitively expensive to resolve)
311	Unable to Attend - Matters beyond our reasonable control (e.g. weather)
312	Unable to Attend - Network or Systems not ready or Wayleave/survey not completed in time
313	Fault at Node (or between Toby and Node)
314	Fault at POP (or between Node and POP)
315	Fault at ONT (or between Toby and ONT)
316	Partial Install, additional service failed
317	Selected ENNI/sVLAN/cVLAN not available
318	No fibre route or insufficient capacity [used in alaOrderCancelled]
319	Invalid Appointment Configuration
320	New Acquisition
321	No Truck Roll
322	Unable to install auxiliary service (Faulty / Missing / Unsuitable)
399	Other reason
9120	SP REQUESTED CANCEL OTHER - NO AUTHORISATION GIVEN TO TRANSFER
9150	SP REQUESTED CANCEL OTHER - CUSTOMER HAS NEVER BEEN CONTACTED
9160	SP REQUESTED CANCEL OTHER - DELIBERATE ATTEMPT TO MISLEAD
9170	SP REQUESTED CANCEL OTHER - PURCHASED A DIFFERENT PRODUCT/SERVICE
9190	SP REQUESTED CANCEL OTHER - END USER NOT MOVING

errorCode

Code	Description
500	Property unknown or not in coverage area
501	Property not RFS_1 or available for preorder
502	Property already has active service
503	No fibre route or insufficient capacity [used in alaOrderRejected]
504	Unknown or invalid service ID
505	Service is not active
506	Invalid appointment type
507	Invalid product or product options (line profile, auxiliary services)
509	No available appointment slot
510	Unknown, invalid or expired reservation ID
511	Unknown, invalid or expired Project Reference
512	Invalid order type
520	Reserved (to avoid confusion with corresponding Openreach status codes)
530	Reserved (to avoid confusion with corresponding Openreach status codes)
540	Reserved (to avoid confusion with corresponding Openreach status codes)
598	Invalid arguments
599	System error

Next Best Actions

Description
Before reappointing, please engage customer and mitigate on-site pet animal hazard. Reappoint with the customer after completion of contact and agreed action.
CityFibre have declared MBORC. Please await further information.
During our pre-checks we've identified an issue in our network. We're working to resolve. Check API/Portal updates for the latest status. No action needed from the ISP
It's important to ensure that the necessary permissions are obtained ahead of the installation. Once the customer has received permission from their landlord, please re-appoint the service. If not granted, please cancel the service.
It's important to ensure that the necessary permissions are obtained ahead of the installation. Once the customer has received permission from their neighbours, please re-appoint the service. If not granted, please cancel the service.
It's important to ensure that the necessary permissions are obtained ahead of the installation. Once the customer has received permission, please re-appoint the service. If not granted, please cancel the service.
Kindly get in touch with the customer as the installation has been declined whilst onsite as they are stating they never ordered it. Please re-appoint or cancel the order depending on the conversation with the customer
Kindly get in touch with the customer to determine if they wish to proceed with installation and reschedule if required, as the installation has been declined whilst onsite. Please re-appoint or cancel the order depending on the conversation with the customer
On arrival at the premises, we've identified that it's been converted into multiple properties. This means at this time we need to review how we serve this property as the designated fibre is already in use.
On arrival the premises looks to be vacant and unoccupied. Please engage with the customer and reappoint when confirmed by the customer they are available.
Our engineer has raised that they encountered incidents of improper conduct during their visit to the customer. As a precautionary measure, it is advisable to communicate with the client before arranging any future appointment.
Our engineers faced a hazard onsite. The customer must remove all hazards before continuing work to ensure everyone's safety. Please collaborate with the customer to fix the problem before scheduling another appointment.
Our engineers faced an unsafe work environment. The customer must remove all hazards before continuing work to ensure everyone's safety. Please collaborate with the customer to fix the problem before scheduling another appointment.
Our engineers faced scaffolding in the environment. We cannot work whilst this exists. The customer must remove this before continuing work. Please collaborate with the customer to fix the problem before scheduling another appointment.
Our team is aware of a network issue affecting light reaching customer's property. We're working to resolve it as quickly as possible. Check API/portal for updates. No action required from ISP.
The address on the order is incorrect. Please check it is correct and reorder if not at the correct address.
The customer cancelled the visit when our engineer called them. Please engage and re-appoint the order
The customer changed the appointment beyond the point of no return. No action required other than confirming
The customer has a query which is relevant to you and needs resolving before they wish to proceed with the installation. Please can you speak to the customer and resolve their query before re-appointing.
The customer told us on pre-call / text they were unwell and not available for the appt. Please can you contact the customer and re-appoint for a time when they are feeling better.
The installation cannot proceed due to an asbestos risk encountered by our engineer. The customer must address this issue before we can continue with the installation. Only reappoint once the issue has been mitigated.
The recommended external network route was not feasible option for the customer. Please engage the customer to explore alternative locations. If none of the options work, please can cancel the service or reappoint if a viable route can be agreed.
The recommended internal network route was not feasible option for the customer. Please engage the customer to explore alternative locations. If none of the options work, please can cancel the service or reappoint if a viable route can be agreed.
The recommended network route was not feasible option for the customer. Please engage the customer to explore alternative locations. If none of the options work, please can cancel the service or reappoint if a viable route can be agreed.
There was an issue during installation that we are working to resolve. Check API/portal updates for the latest status. No action needed from the ISP.
There was an issue during installation that we are working to resolve. Check API/portal updates for the latest status. No action needed from the ISP. No action for ISP at this time
There was an issue with accessing the customer's flat roof, our team is working hard to find a solution. Stay up-to-date on the latest status in the API/portal. There is no need for any ISP action at this time.
We couldn't locate the property on our visit. Please provide more location information or landmarks to help the next engineer. Please reappoint with additional information
We're sorry for not being able to meet the scheduled appointment. Please re-appoint
We've encountered a network issue during installation, but we're working on it. Check the API/portal for updates on your order. No action needed on your end.
We've visited the property today and nobody was in. Please re-appoint.
Your customer has amended their appointment. No action required for the ISP
Your customer has cancelled the appointment. Please contact the customer and engage them to reappoint the order.
We've amended your customers appointment. No action required for the ISP.
We've encountered a network issue during remote activation. The ONT may have been switched off or have been removed. Please reappoint for an engineer visit.
We've encountered a network issue during remote activation. Please reappoint for an engineer visit.
During our pre-checks we've identified an issue in our network that's preventing us providing service on the chosen appointment day. We're working hard to resolve, please check API/Portal updates for the latest status after 48 hours. No action needed from the ISP.

Addresses

The buyer can query address availability. The buyer can search by postcode to get a list of locations which may be available to order on in that region or may look up a single address via UPRN

Query Address Search

To check the availability on a given location, The buyer should send a request containing either a postcode or a UPRN.

The seller is then going to respond with detailed information about the queried location.

If the buyer queried using a UPRN, the response will contain only one location.

On a postcode request, the seller might respond with multiple locations that match the given postcode.

The location details include among other fields: UPRN, RFS (Ready For Service) status, cabinet release date, LOC (Limit Of Construction), if the order will be a preorder (aka <cfh:preOrder/> XML tag is returned).

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	Address Key (object) or Postcode (object)

Responses

200

Query Address Search Response

400

Failed XML Schema Validation

401

Unauthorized

403

Unauthenticated

post/queryAddressSearch

Request samples

Payload
curl
PHP
Python

application/xml

<queryAddressSearchRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <location>
    <addressKey>123456</addressKey>
  </location>
</queryAddressSearchRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <queryAddressSearchResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
      <message>
        <messageId>5cd77a84-f329-4cec-af7e-521e7a7e0861</messageId>
        <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
        <sentAt>2017-10-18T17:10:33Z</sentAt>
      </message>
      <buyer>
        <buyerIdentifier>SPDEV1</buyerIdentifier>
      </buyer>
      <seller>
        <sellerIdentifier>CITYFIBRE</sellerIdentifier>
      </seller>
      <queryAddressSearchAccepted>
        <locations>
          <location>
            <addressKey>200002813013</addressKey>
            <addressKeyType>
              <recognisedAddressKey/>
            </addressKeyType>
            <britishAddress>
              <buildingNumber>12</buildingNumber>
              <dependentThoroughfareName>CROSS LANE</dependentThoroughfareName>
              <thoroughfareName>BRIDGE STREET</thoroughfareName>
              <postTown>LONDON</postTown>
              <postcode>SW1A 2JX</postcode>
            </britishAddress>
            <gpsCoordinates>
              <gpsLatitude>N 51 50.114</gpsLatitude>
              <gpsLongitude>W 0 12.847</gpsLongitude>
            </gpsCoordinates>
            <cfh:rfs_status>RFS_4</cfh:rfs_status>
            <cfh:cabinet_area>YO-CB01</cfh:cabinet_area>
            <cfh:cabinet_release_date>2017-10-01</cfh:cabinet_release_date>
            <cfh:cabinet_date_rating>DR0</cfh:cabinet_date_rating>
            <cfh:property_classification>Residential</cfh:property_classification>
            <cfh:demand_point_type_category>Individual property</cfh:demand_point_type_category>
            <cfh:drop_architecture_type_category>Underground</cfh:drop_architecture_type_category>
          </location>
          <location>
            <addressKey>200002813014</addressKey>
            <addressKeyType>
              <recognisedAddressKey/>
            </addressKeyType>
            <britishAddress>
              <buildingNumber>14</buildingNumber>
              <dependentThoroughfareName>CROSS LANE</dependentThoroughfareName>
              <thoroughfareName>BRIDGE STREET</thoroughfareName>
              <postTown>LONDON</postTown>
              <postcode>SW1A 2JX</postcode>
            </britishAddress>
            <cfh:rfs_status>RFS_1</cfh:rfs_status>
            <cfh:cabinet_area>YO-CB01</cfh:cabinet_area>
            <cfh:cabinet_release_date>2017-10-01</cfh:cabinet_release_date>
            <cfh:cabinet_date_rating>DR0</cfh:cabinet_date_rating>
            <cfh:property_classification>Residential</cfh:property_classification>
            <cfh:demand_point_type_category>Maisonette</cfh:demand_point_type_category>
            <cfh:drop_architecture_type_category>Underground</cfh:drop_architecture_type_category>
          </location>
          <location>
            <addressKey>200002813015</addressKey>
            <addressKeyType>
              <recognisedAddressKey/>
            </addressKeyType>
            <britishAddress>
              <organisationName>CLIFTON MOOR CHURCH &amp; COMMUNITY CENTRE</organisationName>
              <dependentThoroughfareName>CROSS LANE</dependentThoroughfareName>
              <thoroughfareName>RIVELIN WAY</thoroughfareName>
              <postTown>YORK</postTown>
              <postcode>YO30 4WD</postcode>
            </britishAddress>
            <cfh:rfs_status>NOT_RFS_3</cfh:rfs_status>
            <cfh:cabinet_area>YO-CB01</cfh:cabinet_area>
            <cfh:cabinet_release_date>2017-10-01</cfh:cabinet_release_date>
            <cfh:cabinet_date_rating>DR0</cfh:cabinet_date_rating>
            <cfh:loc_flags>WAY UEL UST</cfh:loc_flags>
            <cfh:property_classification>Residential</cfh:property_classification>
            <cfh:demand_point_type_category>Small apartment block</cfh:demand_point_type_category>
            <cfh:drop_architecture_type_category>Overground</cfh:drop_architecture_type_category>
          </location>
        </locations>
      </queryAddressSearchAccepted>
    </queryAddressSearchResponse>
  </soap:Body>
</soap:Envelope>

Appointments

The buyer can query appointment availability, reserve an appointment and include the reservation key in the order request. If this is not done, the order will go into a waiting state and not asgress, the buyer will need to reserve an appointment and then amend the order to include the appointment reservation key before the order can complete.

Query Appointment Availability

To check the availability for an appointment on a given location, timeframe, and product.

The buyer should send a request containing a UPRN.

The seller is then going to respond with detailed information about available appointment slots.

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
addressKey required	string (addressKey) <= 63 characters Unique identifier of the address (UPRN)
appointmentsFrom required	string <date> <= 10 characters Appointments in the future from this date
required	Order (object) or Fault (object) (appointmentType)
cfh:productName required	string <= 254 characters Name of the Product
cfh:ispMigration	string Flag for ISP Migration
cfh:reappointment	string Indicates whether the appointment is reappointing a previous appointment
cfh:projectReference	string <= 80 characters

Responses

200

Appointment Availability Response

400

Failed XML Schema Validation

401

Unauthorized

403

Unauthenticated

post/queryAppointmentAvailability

Request samples

Payload
curl
PHP
Python

application/xml

<queryAppointmentAvailabilityRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <addressKey>10002491172</addressKey>
  <appointmentsFrom>2017-10-18</appointmentsFrom>
  <appointmentType>
    <order/>
  </appointmentType>
  <cfh:productName>ftthl2r</cfh:productName>
  <cfh:ispMigration>false</cfh:ispMigration>
  <cfh:reappointment>false</cfh:reappointment>
</queryAppointmentAvailabilityRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <queryAppointmentAvailabilityResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
      <message>
        <messageId>bf1efe1f-f5fc-47e7-9d53-d2b16529aa4c</messageId>
        <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
        <sentAt>2022-05-18T11:23:07.710Z</sentAt>
      </message>
      <buyer>
        <buyerIdentifier>SPDEV1</buyerIdentifier>
      </buyer>
      <seller>
        <sellerIdentifier>CITYFIBRE</sellerIdentifier>
      </seller>
      <queryAppointmentAvailabilityAccepted>
        <appointmentSlots></appointmentSlots>
      </queryAppointmentAvailabilityAccepted>
    </queryAppointmentAvailabilityResponse>
  </soap:Body>
</soap:Envelope>

Reserve Appointment

In order to reserve an appointment, the buyer should provide the UPRN, product and the appointment slot that they desire to the seller

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (appointmentSlot) Represents the appointment slot details (date, start time, end time)
required	Order (object) or Fault (object) (appointmentType)
cfh:productName required	string <= 254 characters This is the product name
cfh:addressKey required	string <= 254 characters The address key (UPRN)
cfh:ispMigration	string Flag for ISP Migration
cfh:reappointment	string Indicates whether the appointment is reappointing a previous appointment
cfh:projectReference	string <= 80 characters

Responses

200

Reserve Appointment Response

400

Failed XML Schema Validation

401

Unauthorized

403

Unauthenticated

post/reserveAppointment

Request samples

Payload
curl
PHP
Python

application/xml

<reserveAppointmentRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <appointmentSlot>
    <appointmentDate>2012-01-20</appointmentDate>
    <appointmentStartTime>08:00</appointmentStartTime>
    <appointmentEndTime>13:00</appointmentEndTime>
  </appointmentSlot>
  <appointmentType>
    <order/>
  </appointmentType>
  <cfh:productName>ftthl2r</cfh:productName>
  <cfh:addressKey>123456789012</cfh:addressKey>
  <cfh:ispMigration>false</cfh:ispMigration>
  <cfh:reappointment>false</cfh:reappointment>
</reserveAppointmentRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <reserveAppointmentResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
      <message>
        <messageId>c6d0b303-625a-4ee3-ab53-5e616d728755</messageId>
        <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
        <sentAt>2022-05-20T09:58:23.439Z</sentAt>
      </message>
      <buyer>
        <buyerIdentifier>SPDEV1</buyerIdentifier>
      </buyer>
      <seller>
        <sellerIdentifier>CITYFIBRE</sellerIdentifier>
      </seller>
      <reserveAppointmentAccepted>
        <appointment>
          <appointmentDate>2022-05-24</appointmentDate>
          <appointmentStartTime>08:00</appointmentStartTime>
          <appointmentEndTime>13:00</appointmentEndTime>
          <appointmentReservationKey>EI7PBRU6TL8KN1YNGO8ICEUI0UDFE9M8</appointmentReservationKey>
          <appointmentReservationValidUntil>2022-05-20T21:58:26.822Z</appointmentReservationValidUntil>
        </appointment>
      </reserveAppointmentAccepted>
    </reserveAppointmentResponse>
  </soap:Body>
</soap:Envelope>

Orders

An order can be accepted for any RFS_[1-4] property.

Create NewInstall Order

Place an order for a new service

The ALA Provider will respond with an orderResponse to signify that the request has been accepted for processing. Subsequent updates about the order will be provided via NotifyOfOrderStatus

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (newOrderReferences) Reference for the order for this buyer
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	PPPoE (object) or L2DHCP (object) (alaNewInstall)

Responses

200

Order request doesn't have any informative response (except 400, 401, 403 errors like Amend & Cancel) so Order Response is empty by default. We use NotifyOfOrderStatus instead to provide all useful information about the Order.

400

Broken XML (400 Bad Request)

401

Unauthorized

403

Unauthenticated

post/order

Request samples

Payload
curl
PHP
Python

application/xml

<orderRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <orderReferences>
    <buyerOrderReference>CST1234567</buyerOrderReference>
  </orderReferences>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <alaNewInstall>
    <cfh:ispMigration>false</cfh:ispMigration>
    <location>
      <addressKey>200004753612</addressKey>
    </location>
    <site>
      <accessRestrictions>Access-related issue</accessRestrictions>
      <hazards>Hazard-related issue</hazards>
      <onSiteContactDetails>
        <primaryContact>
          <name>bob bob</name>
          <email>bob@bob.com</email>
          <telephoneNumber>+12345678987654</telephoneNumber>
        </primaryContact>
        <additionalContacts>
          <additionalContact>
            <name>bob bob</name>
            <email>bob@bob.com</email>
            <telephoneNumber>+12345678987654</telephoneNumber>
          </additionalContact>
        </additionalContacts>
      </onSiteContactDetails>
    </site>
    <appointment>
      <appointmentReservationKey>1234567</appointmentReservationKey>
    </appointment>
    <serviceItem>
      <product>
        <productName>ftthl2r</productName>
      </product>
      <alaServiceConfiguration>
        <cfh:lineProfile>G1000/35/70</cfh:lineProfile>
        <pppoeIntermediateAgent><enabled/></pppoeIntermediateAgent>
        <aucRemoteId>A123</aucRemoteId>
      </alaServiceConfiguration>
      <auxiliaryServices>
        <auxiliaryService>
          <auxiliaryServiceName>CPEInst1</auxiliaryServiceName>
        </auxiliaryService>
      </auxiliaryServices>
    </serviceItem>
  </alaNewInstall>
</orderRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <orderResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1"/>
  </soap:Body>
</soap:Envelope>

Create Modify Order

Request a change to an active service

The ALA Provider will respond with an orderResponse to signify that the request has been accepted for processing. Subsequent updates about the order will be provided via NotifyOfOrderStatus

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (orderReferences) Reference for the order for this buyer
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (alaModify)

Responses

200

400

Failed XML Schema Validation

401

Unauthorized

403

Unauthenticated

post/orderModify

Request samples

Payload
curl
PHP
Python

application/xml

<orderRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <orderReferences>
    <buyerOrderReference>CST1234567</buyerOrderReference>
  </orderReferences>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <alaModify>
    <serviceIdentifier>SI2345432345345</serviceIdentifier>
    <serviceItem>
      <alaServiceConfiguration>
          <cfh:lineProfile>G1000/35/70</cfh:lineProfile>
      </alaServiceConfiguration>
    </serviceItem>
  </alaModify>
</orderRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <orderResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1"/>
  </soap:Body>
</soap:Envelope>

Create Cease Order

Request that an active service is ceased

The ALA Provider will respond with an orderResponse to signify that the request has been accepted for processing. Subsequent updates about the order will be provided via NotifyOfOrderStatus

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (orderReferences) Reference for the order for this buyer
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (alaCease)

Responses

200

400

Broken XML (400 Bad Request)

401

Unauthorized

403

Unauthenticated

post/ceaseOrder

Request samples

Payload
curl
PHP
Python

application/xml

<orderRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <orderReferences>
    <buyerOrderReference>CST1234567</buyerOrderReference>
  </orderReferences>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <alaCease>
    <serviceIdentifier>SI2345432345345</serviceIdentifier>
  </alaCease>
</orderRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <orderResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1"/>
  </soap:Body>
</soap:Envelope>

Amend an Order

Request to amend an in flight order.

An ALA Provider can either respond that the amendment is pending or can reject the amendment up front.

SecurityCertificate

Request

Request Body schema: application/xml

One of:

Request to amend an in flight order.

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (orderReferences) Reference for the order for this buyer
targetSellerOrderReference required	string
	object (serviceItem)

Responses

200

Amend Order Response

400

Broken XML (400 Bad Request)

401

Unauthorized

403

Unauthenticated

post/amendOrder

Request samples

Payload
curl
PHP
Python

application/xml

<amendOrderRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <orderReferences>
    <buyerOrderReference>CST999006-1</buyerOrderReference>
  </orderReferences>
  <targetSellerOrderReference>CFH123456543</targetSellerOrderReference>
  <serviceItem>
    <alaServiceConfiguration>
      <nniIdentifier>S1945</nniIdentifier>
      <nniSVlanId>24</nniSVlanId>
      <nniCVlandId>1234</nniCVlandId>
    </alaServiceConfiguration>
  </serviceItem>
</amendOrderRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <amendOrderResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
      <message>
        <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
        <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
        <sentAt>2012-01-20T18:30:43Z</sentAt>
      </message>
      <buyer>
        <buyerIdentifier>SPDEV1</buyerIdentifier>
      </buyer>
      <seller>
        <sellerIdentifier>CITYFIBRE</sellerIdentifier>
      </seller>
      <orderReferences>
        <buyerOrderReference>CST999006-1</buyerOrderReference>
      </orderReferences>
      <amendmentPending/>
    </amendOrderResponse>
  </soap:Body>
</soap:Envelope>

Cancel an Order

Request to cancel an in flight order

The ALA Provider can either respond that the cancellation is pending or reject it up front.

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (orderReferences) Reference for the order for this buyer
targetSellerOrderReference required	string
required	object (cancellationReason)

Responses

200

Cancel Order Response

400

Broken XML (400 Bad Request)

401

Unauthorized

403

Unauthenticated

post/cancelOrder

Request samples

Payload
curl
PHP
Python

application/xml

<cancelOrderRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <orderReferences>
    <buyerOrderReference>CST999005-5</buyerOrderReference>
  </orderReferences>
  <targetSellerOrderReference>CFH123456543</targetSellerOrderReference>
  <cancellationReason>
    <cancellationReasonCode>300</cancellationReasonCode>
    <cancellationReasonMessage>No longer required</cancellationReasonMessage>
  </cancellationReason>
</cancelOrderRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <cancelOrderResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
      <message>
        <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
        <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
        <sentAt>2012-01-20T18:30:43Z</sentAt>
      </message>
      <buyer>
        <buyerIdentifier>SPDEV1</buyerIdentifier>
      </buyer>
      <seller>
        <sellerIdentifier>CITYFIBRE</sellerIdentifier>
      </seller>
      <orderReferences>
        <buyerOrderReference>CST999005-5</buyerOrderReference>
      </orderReferences>
      <cancellationPending/>
    </cancelOrderResponse>
  </soap:Body>
</soap:Envelope>

Products

The buyer can query product availability at a given UPRN. For more information about products please see the reference

Query Products for Location

Check the available products for a given location using the location's UPRN.

The seller will then respond with a list of one or multiple available products (if any) along with information about the need for an appointment (yes/no/maybe). For more information on products see the reference

Some products such as auxiliary services could depend on other products (this is indicated via the dependsOn property). For example ResVOIP1 can depend on CPEInst1, meaning if ResVOIP1 is ordered then CPEInst1 needs to be requested as well.

SecurityCertificate

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (Address Key)

Responses

200

Query Products For Location Response

400

Failed XML Schema Validation

401

Unauthorized

403

Unauthenticated

post/queryProductsForLocation

Request samples

Payload
curl
PHP
Python

application/xml

<queryProductsForLocationRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <location>
    <addressKey>123456</addressKey>
  </location>
</queryProductsForLocationRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <queryProductsForLocationResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
      <message>
        <messageId>560207a5-c6ff-42f5-9e4c-fa0175bc8704</messageId>
        <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
        <sentAt>2017-10-12T13:09:06Z</sentAt>
      </message>
      <buyer>
        <buyerIdentifier>SPDEV1</buyerIdentifier>
      </buyer>
      <seller>
        <sellerIdentifier>CITYFIBRE</sellerIdentifier>
      </seller>
      <queryProductsForLocationAccepted>
        <locations>
          <location>
            <addressKey>200004753569</addressKey>
            <addressKeyType>
              <recognisedAddressKey/>
            </addressKeyType>
            <availableProducts>
              <availableProduct>
                <productName>ftthl2r</productName>
                <appointmentRequired>
                  <maybe/>
                </appointmentRequired>
                <cfh:nnis>
                  <nniIdentifier>S123435</nniIdentifier>
                </cfh:nnis>
              </availableProduct>
              <availableProduct>
                <productName>ftthl2b</productName>
                <appointmentRequired>
                  <maybe/>
                </appointmentRequired>
                <cfh:nnis>
                  <nniIdentifier>S123435</nniIdentifier>
                </cfh:nnis>
                <cfh:availableLineProfiles>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>90/90/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>1000/1000/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>110/110/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>220/220/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>550/550/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>45/45/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                  <cfh:availableLineProfile>
                    <cfh:lineProfile>2200/1000/A/V</cfh:lineProfile>
                  </cfh:availableLineProfile>
                </cfh:availableLineProfiles>
              </availableProduct>
            </availableProducts>
          </location>
        </locations>
      </queryProductsForLocationAccepted>
    </queryProductsForLocationResponse>
  </soap:Body>
</soap:Envelope>

Order Status

Notify Of Order StatusWebhook

Messages sent back to the ALA user to indicate progress of an order.

To facilitate correct construction of messages, these messages will either contain an alaOrderInProgress message if the order is in progress, alaOrderFailed if the order has failed or cancelled and alaOrderCompleted if the order has completed.

Request

Request Body schema: application/xml

One of:

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (newOrderReferences) Reference for the order for this buyer
issuedAt required	string <date-time> (issuedAt) The timestamp when the order status notification has been issued at
sequenceNumber required	number (sequenceNumber)
required	Pending (object) or Acknowledged (object) or Committed (object)
required	object (alaOrderInProgress)
	Array of objects (notes)

Responses

200

Acknowledgement of the message.

Request samples

Payload

application/xml

<notifyOfOrderStatus xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" xmlns:cfh="http://www.cityfibre.com/ala/ext1">
  <message>
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <orderReferences>
    <buyerOrderReference>CST1234567</buyerOrderReference>
    <sellerOrderReference>CFH123456543</sellerOrderReference>
  </orderReferences>
  <issuedAt>2012-01-20T18:30:43Z</issuedAt>
  <sequenceNumber>0</sequenceNumber>
  <alaOrderStatus>
    <pending/>
  </alaOrderStatus>
  <alaOrderInProgress />
  <notes>
    <note>No Toby to property</note>
  </notes>
</notifyOfOrderStatus>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <notifyOfOrderStatusResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" />
  </soap:Body>
</soap:Envelope>

Unsolicited Cease

Unsolicited CeaseWebhook

Request

Request Body schema: application/xml

required	object (message) The meta-data of the request. It includes information regarding the message UUID, transaction ID and the sent timestamp
required	object (buyer) The Service Provider who consumes the service is the buyer
required	object (seller) the Active Network Operator who provides the service is the seller
required	object (orderReferences) Reference for the order for this buyer
serviceIdentifier required	string (serviceIdentifier) <= 36 characters Unique Identifier for the service
requestedDate required	string <date-time> (requestedDate) Point at which the change should be applied
cfh:newOrderType	string (newOrderType) Order type options: `Regrade` - where the end customer is changing to a new product `Switch` - where the end customer is changing to a new internet provider (Buyer) `WLTO` - where the end customer is moving to a new location Enum: "Regrade" "Switch" "WLTO"
notes	string (note) <= 2047 characters

Responses

200

Acknowledgement of the message.

Request samples

Payload

application/xml

<unsolicitedCeaseRequest xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd">
  <message>  
    <messageId>b68b2cf4-475e-11e1-a92e-fb2ff6467c99</messageId>
    <correlationId>bac72cfa-475e-11e1-a92e-fb2ff6467c99</correlationId>
    <sentAt>2012-01-20T18:30:43Z</sentAt>
  </message>
  <buyer>
    <buyerIdentifier>SPDEV1</buyerIdentifier>
  </buyer>
  <seller>
    <sellerIdentifier>CITYFIBRE</sellerIdentifier>
  </seller>
  <orderReferences>
    <sellerOrderReference>CFH123456543</sellerOrderReference>
  </orderReferences>
  <serviceIdentifier>SI2345432345345</serviceIdentifier>
  <requestedDate>2012-01-20T18:30:43Z</requestedDate>
  <notes></notes>
</unsolicitedCeaseRequest>

Response samples

application/xml

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <unsolicitedCeaseResponse xmlns="http://www.niccstandards.org.uk/ala_1.0.xsd" />
  </soap:Body>
</soap:Envelope>

Code	Name	Description
fttpl2bs	Layer 2 FTTP 1.0Gbps Business Local Handoff	Layer 2 FTTP 1.0Gbps Business (Standard) Local Handoff
ftthl2b	FTTH L2 Business	Layer 2 FTTP 1000Mbps Business Premium Local Handoff
ftthl2r	FTTH L2 Residential	FTTH Layer 2 Local Residential Service
ftthl2rn	FTTH L2 National Residential	FTTP Layer 2 National Residential Service
fttpl2bsn	Layer 2 FTTP 1.0Gbps Business National Handoff	Layer 2 FTTP 1.0Gbps Business (Standard) National Handoff
fttpl2bn	FTTP L2 National Business	Layer 2 FTTP 1000Mbps Business Premium National Handoff
fttpl2rlite	FTTP L2 Residential 160	FTTP Layer 2 Local Residential Service
fttpl2rnlite	FTTP L2 National Residential 160	FTTP Layer 2 National Residential Service
fttpl2blite	FTTP L2 Business 160	FTTP Layer 2 Local Business Service
fttpl2bnlite	FTTP L2 National Business 160	FTTP Layer 2 National Business Service
fttpl2b-2500l	Layer 2 FTTP 2.5Gbps Business Local Handoff	Layer 2 FTTP 2.5Gbps Business Local Handoff
fttpl2b-2500n	Layer 2 FTTP 2.5Gbps Business National Handoff	Layer 2 FTTP 2.5Gbps Business National Handoff
fttpl2b-2000l	Layer 2 FTTP 2.0Gbps Business Local Handoff	Layer 2 FTTP 2.0Gbps Business Local Handoff
fttpl2b-2000n	Layer 2 FTTP 2.0Gbps Business National Handoff	Layer 2 FTTP 2.0Gbps Business National Handoff
fttpl2b-1200l	Layer 2 FTTP 1.2Gbps Business Local Handoff	Layer 2 FTTP 1.2Gbps Business Local Handoff
fttpl2b-1200n	Layer 2 FTTP 1.2Gbps Business National Handoff	Layer 2 FTTP 1.2Gbps Business National Handoff
fttpl2b-1200al	Layer 2 FTTP 1.2Gbps Business Local Handoff Asymmetric	Layer 2 FTTP 1.2Gbps Business Local Handoff Asymmetric
fttpl2b-1200an	Layer 2 FTTP 1.2Gbps Business National Handoff Asymmetric	Layer 2 FTTP 1.2Gbps Business National Handoff Asymmetric
fttpl2r-2500l	Layer 2 FTTP 2.5Gbps Residential Local Handoff	Layer 2 FTTP 2.5Gbps Residential Local Handoff
fttpl2r-2500n	Layer 2 FTTP 2.5Gbps Residential National Handoff	Layer 2 FTTP 2.5Gbps Residential National Handoff
fttpl2r-2000l	Layer 2 FTTP 2.0Gbps Residential Local Handoff	Layer 2 FTTP 2.0Gbps Residential Local Handoff
fttpl2r-2000n	Layer 2 FTTP 2.0Gbps Residential National Handoff	Layer 2 FTTP 2.0Gbps Residential National Handoff
fttpl2r-1200l	Layer 2 FTTP 1.2Gbps Residential Local Handoff	Layer 2 FTTP 1.2Gbps Residential Local Handoff
fttpl2r-1200n	Layer 2 FTTP 1.2Gbps Residential National Handoff	Layer 2 FTTP 1.2Gbps Residential National Handoff
fttpl2r-1200al	Layer 2 FTTP 1.2Gbps Residential Local Handoff Asymmetric	Layer 2 FTTP 1.2Gbps Residential Local Handoff Asymmetric
fttpl2r-1200an	Layer 2 FTTP 1.2Gbps Residential National Handoff Asymmetric	Layer 2 FTTP 1.2Gbps Residential National Handoff Asymmetric