Vocalink Proxy

Vocalink proxy used by the services that want to communicate with Vocalink API and store simple client attributes

The main endpoints are:

  1. /v1/client-info - CRUD endpoint for adding JSON key-values tied to a tenantKey.
  2. /v1/feedback - POSTable endpoint for feedback submission to Vocalink, and upon success, another POST is performed against the CMS Case API to record the successful feedback event.
  3. /v1/vocalink/... - Proxy requests directly to the VL API with proper authentication headers added minus the /v1/vocalink prefix.

Usage

Client Attributes

Client attributes are a collection of manually-set JSON keys and values for a given tenant. Under a user for a given tenant:

  1. Query GET /v1/client-info to retrieve all the client attributes for that given tenant from the Config Service.

You must store client attributes in the Config Service under /default/tenantAttributes. This is just a proxy.

Case Feedback

{{TODO: What are the ROLES required? Now, none}}

Feedback from a case needs to be submitted to Vocalink, and upon success, the results need to be sent to the Case API. Feedback can be from a single case (the payload is an object), or an array of cases (the payload is an array of objects). The bare minimum information in the JSON object payloads is:

FeedbackPayload {
    eventID: number;
    caseID: number;
}

Upon success from a VL API submission, each object is sent to the following Case API endpoint:

${CMS_CASE_API_HOST}/v1/cases/${payload.caseID}/events/${payload.eventID}/feedback

If one or more submissions to the VL API fails for whatever reason, a list of failures is returned to the feedback caller. The very last failure response code is what is returned to the feedback submitter. For example, if an array of feedback objects is submitted and one results in 200 and the other results in 400, then the overall response code will be 400.

Passthru Proxy

{{TODO: What are the ROLES required? Now, none}}

To avoid each microservice needing to authenticate with the VL API, this proxy service forwards requests to the VL API with authentication headers added.

Example Proxied Requests

GET {vl-proxy-hostname}/v1/vocalink/foo/bar --> GET {vl-api}/foo/bar
POST {vl-proxy-hostname}/v1/vocalink/baz?id=1 --> POST {vl-api}/baz?id=1

Prefix any VL API request path with /v1/vocalink/ to cause the request to proxied to the VL API.

VL API Keys

These must be injected at container start-time for each tenant, and must follow the following pattern:

<tenantKey>_apiKey=<key>
<tenantKey>_clientId=<clientId>

For example,

MyTenant_apiKey=ab3b5befbf...
MyTenant_clientId=809367
← Configuration API