Methods
The following are the API methods available in the OneVu API.
In order to call the APIs you need the following setting to be enabled behind the scenes:
ApiKeySecurityEnabled
If you're licensed to use this functionality, you simply need to request this to be enabled via the support desk:
Once this has been enabled you will be able to create an API key which you can then use to call the APIs.
Creating an API Key
These are created within the API Developer Access screen within OneVu Control, as shown below:
Within here click Add to create an API Key. When you have you'll need to give it a name and description as shown below:
Note the name of the API key will be used when updating things for audit purposes. So it it is important to name these wisely.
When you click save you will be presented with a one time only view of the API Key and The API Key ID.
These are then used when calling the APIs.
Customer Methods
Finding a customer's details
This API will provide you with the name, address, email if their id is passed:
Departmental / Data (Card) Methods
OneVu's 'Cards' are the various departments presented in the 'Get Answers Fast' screen.
There are six API methods available as shown below:
Get customers/{customerId}/cards
To find out the departments available you simply need to provide this API with the customerId. This API provides a different 'cardId' for each department as well as Summary Fields to make it obvious as to what the department is.
This API will search OneVu to find the departments and content available for the user in question.
This provide details of:
the name and description of every department available
whether it is personalisable and whether it has been personalised
the direct links to the 'child' APIs for the customer to enable automated subsequent calling of these
the summary fields are shown on personalised cases. These will be things like the account/claim/case reference/postcode
It should be noted that IF a person has personalised more than 1 account/claim etc. within a silo, a separate card will be shown for EACH personalised account. E.g. the following was returned for the first personalised account in IEG4's own internal Council Tax app:
Get customers/{customerId}/cards/{cardId}/data-items
To find out the data items (the specific elements of data) within a given department you call this API using the customerId and the CardId that was retrieved in the /cards API method.
This will provide the actual values of all data items that would be used in personalised content within OneVu.
This API is useful for anyone wishing to access data from line of business applications in a consistent manner. The data items provided are all of the elements of data available for a department and these can be used to power a chatbot or external application.
The following shows an example response if we choose to select the Council Tax department.
What makes this impressive is that this is a JSON based rendering of the results of multiple Civica Council Tax API calls. So someone can build retrieve data from a legacy back office that uses legacy middleware and protocols using the latest/greatest standards.
Get customers/{customerId}/cards/{cardId}/personalized-contents
This enables one to find out the high level FAQs and content in a department, which contain personalised data.
This API needs the customerId and the CardId that was retrieved in the /cards API method.
The following shows an example response if we choose to select the Council Tax department.
Get customers/{customerId}/cards/{cardId}/personalized-contents/tiles/{itemId}
This enables one to find out the specific detail of a personalised FAQ within a specific department.
This API needs the customerId, the CardId, and the itemId from those retrieved using the /personalized-contents API method.
Get customers/{customerId}/card-types/{cardTypeId}/static-contents
This enables one to find out the high level FAQs and content in a department, which contain static data.
This API needs the customerId and the CardId that was retrieved in the /cards API method.
The following shows an example response if we choose to select the Council Tax department.
Get customers/{customerId}/card-types/{cardTypeId}/static-contents/tiles/{itemId}
This enables one to find out the specific detail of a static FAQ within a specific department.
This API needs the customerId, the CardId, and the itemId from those retrieved using the /static-contents API method.
Registration Methods
The following are the API methods available to:
a) understand the data needed to authenticate for a given department
b) to actually authenticate a citizen
c) to de-register a citizen from having their personalised data shareable
Get customers/{customerId}/card-types/{cardTypeId}/registration-fields
In order to authenticate a person you need to know which fields are required to authenticate that person.
This time customerId and cardTypeId are needed with the following illustrating the response for the council tax department:
And this for Taxi Licensing:
I.e. irrespective of the back office you have a way in another application to know the fields required to authenticate someone.
Now we know which fields are required we can call the only (currently) one of these APIs that provides a post function - that which enables you to authenticate the customer for a department.
In order to authenticate a person we need to pass:
The customerId
The cardTypeId for the department being authenticated/linked to
a JSON payload containing the answers to the questions we got in the last API (Get Card Registration Fields)
In the above responses to the registration we were given the body of the request for this just missing the values. So we can take what we're given from Get Card Registration Details and simply place the answers the customer provides. In the example below we can see that the values have been provided in situ for a person with the surname Cooper, account no R987123D, House no 1a and Postcode SK9 7RR:
Post customers/{customerId}/card-types/{cardTypeId}/register
This is the API that enables a citizen to be authenticated against a back office application. In order to authenticate a person we need to pass:
The customerId
The cardTypeId for the department being authenticated/linked to
a JSON payload containing the answers to the questions we got in the last API (Get Card Registration Fields)
In the above responses to the registration we were given the body of the request for this just missing the values. So we can take what we're given from Get Card Registration Details and simply place the answers the customer provides. In the example below we can see that the values have been provided in situ for a person with the surname Cooper, account no R987123D, House no 1a and Postcode SK9 7RR:
When complete, the following successful response was returned for the above:
Now, when we call the Get Cards API i.e. the high level summary API we can see this is now available:
I.e. we have just authenticated a customer and linked their customerId to these details. The final API is one that allows us to unlink a user from an account.
Delete customers/{customerId}/cards/{cardTypeId}/register
This API will unlink an account/claim/case etc. from a person's identity. The only fields required for this API are customerId and cardId. So using the above cardId that was generated i.e. 250 and our customerId we can automatically unlink this.
On calling the Get Cards API again one can then see that this was removed.
Avoidable Contact Methods
The following are the different APIs available to retrieve and update the list of avoidable contact reasons:
Timeline Methods
There is currently one method and it enables entries to be added to the OneVu Timeline from external applications:
Broadcast Methods
The following are the API methods available in the context of Broadcast, which enable you to retrieve and update the notifications types available via Broadcast:
Last updated
Was this helpful?