Syftet med API är att låta KO hämta kundinformation om en access från Tjänsteleverantör.
Använd access_sp
- endpointen för att hämta kundinformation med tjänsteleverantörens kundnummer.
Möjlighet att skicka med ett ticket-id eller anledning till varför kunduppgifterna efterfrågas.
OBS! Till skillnad mot andra APIer är KO klient och TL server i detta API.
Request:
GET /api/2.3.1/access/STTA0001 HTTP/1.1
GET /api/2.3.1/access_sp/1337 HTTP/1.1
POST /api/2.3.1/access/STTA0001 HTTP/1.1
Content-Type: application/json
{
"koTicketReference": "123123",
"spTicketReference": "123123",
"reason": "Techinician need to know..."
}
POST /api/2.3.1/access_sp/1337 HTTP/1.1
Content-Type: application/json
{
"koTicketReference": "123123",
"spTicketReference": "123123",
"reason": "Techinician need to know..."
}
Response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"BB-1000-100": {
"customer": {
"name": "Kalle Anka",
"email": "[email protected]",
"phone": "",
"mobilePhone": ""
},
"spReference: "1337",
"accessId": "STTA0001"
}
}
Fält | Förklaring |
service
|
Service är key i root-objektet. Anger teknisk tjänst som skall vara aktiv på accessen. Värden för tekniska tjänster är KO-specifika och erhålls genom Feasibility-APIt. text, obligatoriskt |
customer
|
Syftet med customer är att ge KO information om Tjänsteleverantörens slutkund. JSON-strukturen är obligatorisk och kommer alltid skickas med, men samtliga attribut kan vara tomma. |
customer.phone
|
Exempelformat: +4631650000 |
customer.mobilePhone
|
Exempelformat: +4631650000 |
spReference
|
`spReference` anger TLs referens på tjänsten. Används av TL för korrelering. Sträng, max 255 tecken |
accessId
|
`accessId` blir redundant men skickas med för att göra endpoints enhetliga beroende på vilket kundnummer man efterfrågar med |
Gemensamt för alla fält är att de måste finnas i JSON-strukturen och inte vara null.
POST-parametrarna koTicketReference
spTicketReference
reason
är frivilliga att användas om man vill eller om enskild SP + KO kommer överens om implementation.