Welcome to the Identity Reconciliation API service!

Overview

• The Identity Reconciliation Service is designed to identify and keep track of a user's identity across multiple requests with different contact information.
• This service ensures linking different requests made with different contact information to the same person.
• It is particularly useful in environments where user tries to use different contact information for each request.

You can access the detailed problem statement and solution doc here.

Usage

• The end point /identity receives the HTTP POST requests with JSON body of the following format:

  {
    "email"?: string,
    "phoneNumber"?: number
  }
            

• If successful, the web service returns an HTTP 200 response with a JSON payload containing the consolidated contact.
• The response is in this format:

  {
    "contact":{
      "primaryContactId": number,
      "emails": string[], // first element being email of primary contact
      "phoneNumbers": string[], // first element being phoneNumber of primary contact
      "secondaryContactIds": number[] // Array of all Contact IDs that are "secondary" to the primary contact
    }
  }
            

Working (In case you didn't go through the doc above)

• The system keeps track of the collected contact information in a relational database table named Contact.

  {
    id               Int
    phoneNumber      String?
    email            String?
    linkedId         Int? // the ID of another Contact linked to this one
    linkPrecedence   "secondary"|"primary" // "primary" if it's the first Contact in the chain, otherwise "secondary"
    createdAt        DateTime
    updatedAt        DateTime
    deletedAt        DateTime?
  }
            

• One customer can have multiple Contact rows in the database. All of these rows are linked together, with the oldest one being treated as "primary" and the rest as "secondary."
• Contact rows are linked if they have either the same email or phone number.

For Example

• If a customer placed an order with

  {
    "email": "muzaffar@hillvale.edu"
    "phoneNumber": "123456"
  }
              

  and later came back to place another order with

  {
    "email": "naeem@hillvale.edu"
    "phoneNumber": "123456"
  }
              

• The database will have the following rows:

  {
    id                    1
    phoneNumber           "123456"
    email                 "muzaffar@hillvale.edu"
    linkedId              null
    linkPrecedence        "primary"
    createdAt             2024-04-01 00:00:00.374+00
    updatedAt             2024-04-01 00:00:00.374+00
    deletedAt             null
  },
  {
    id                    23
    phoneNumber           "123456"
    email                 "naeem@hillvale.edu"
    linkedId              1
    linkPrecedence        "secondary"
    createdAt             2024-04-20 05:30:00.11+00
    updatedAt             2024-04-20 05:30:00.11+00
    deletedAt             null
  }
              

Extending the previous example:

• Now the request:

  {
    "email": "naeem@hillvale.edu",
    "phoneNumber": "123456"
  }
              

  will give the following response:

  {
    "contact":{
      "primaryContactId": 1,
      "emails": ["muzaffar@hillvale.edu","naeem@hillvale.edu"]
      "phoneNumbers": ["123456"]
      "secondaryContactIds": [23]
    }
  }
              

• In fact, all of the following requests will return the above response

  {
    "phoneNumber":"123456"
  }
              

  {
    "email": "muzaffar@hillvale.edu"
  }
              

  {
    "email": "naeem@hillvale.edu"
  }