Destinations that require additional keys beyond the common spec should only read from predictable location

[rromanchuk]

What is the difference between

https://github.com/rudderlabs/rudderstack-docs/blame/master/destinations/appsflyer.md#L214

and

https://github.com/rudderlabs/rudder-transformer/blob/master/__tests__/data/af_input.json#L355

integrations.AF.af_uid and context.externalId.0.id, the former makes a lot more sense to me. The documentation makes it sounds as if this externalId type/id array is some sort of pseudo spec. Trying to overload EVERYTHING is a huge PITA and it becomes so unreadable i'm at the point where some values are included at three different key paths for a "pray and spray" to catch inclusion, depending on how the transformer implementer interprets intent through keypath extraction

const afId = message.integrations
    ? message.integrations.AF
      ? message.integrations.AF.af_uid
      : undefined
    : undefined;
  const appsflyerId =
    getDestinationExternalID(message, "appsflyerExternalId") || afId;
  if (!appsflyerId) {
    throw new Error("Appsflyer id is not set. Rejecting the event");
  }

[rromanchuk]

A sample payload for the identify event after removing the common fields mentioned in the Common Fields section:

https://docs.rudderstack.com/rudderstack-api-spec#identify

this example payload has more representations of user id's than i have hours of sleep.

{
  "traits": {
    "id": "hashed_user_id",
    "email": "sample@example.com",
    "userId": "test_user_id",
    "lastname": "Bar",
    "firstname": "Foo"
  },
  "userId": "hashed_user_id"
}