Motivation

The API configuration and call pattern in the SDK is outdated and needs to be brought into correspondence with the current Optable Real-time APIs.

Details

Docs

The documentation for the Optable Real-time APIs is available here: https://docs.optable.co/optable-documentation/admin/real-time-api/api-integrations-guide.

URL components

For the SDK we need to implement the proper configuration - i.e. update the Config class by adding components to it (some may already exist):

• host (na.edge.optable.co by default)
• path (v2 by default)
• endpoint (actual API s.a. identify, targeting, witness, profile, tokenize, but other verbs may be added later - so no need to create a enum for now, especially given there is a wrapper class for each API call anyway)
• tenant
• originSlug

The currently existing app component should be removed. This is a breaking change so will require a major release of the SDK.

Authentication

The APIs can be exposed publicly or privately, for the latter case the apiKey parameter is needed on the Config object. If it is set it should add a header Authorization: Bearer {{API_KEY}} header needs to the API call.

Identifiers

Please extend the identify interface. gaid: can stay as boolean as it is obtained automatically, but instead of just email and ppid - it should take an identifiers: HashMap<String,String> param. A HashMap of prefixes as keys and identifiers as values. email can be one of them it will have e as a prefix, but ppids are not limited to c - they can have a prefix c, but also in a range from c1 to c19. Read a chapter on identifer types and prefixes - these same prefixes are used in forming the request to Identify so you will just use the keys as needed from this HashMap (these same identifiers can also be sent to Targeting API, but Targeting can use solely passport containing a visitor id after identify has linked these to the visitor id. Make sure to document this method well and add links to the above.

Objectives

1. Update the configuration and request forming for the above mentioned API calls
2. Make sure unit tests cover request forming
3. Ideally there should be unit tests against mock server to verify the API request / response end-to-end.