Unclear authorization parameters setting in integration configuration

[listopadiya]

Pizzly instructions on custom integration say that in integration file authorizationParams object contains any static parameters that need to be passed in during authorization. For example, the Discord API expects "response_type": "code" and "grant_type": "authorization_code" to be sent during authorization. Although in some existing integrations there is also auth object which may contain the same parameters.

For example, here response_type is defined in authorizationParams:

{
  "name": "Cronofy",
  "auth": {
    "authType": "OAUTH2",
    "tokenParams": { "grant_type": "authorization_code" },
    "authorizationParams": { "response_type": "code" },
    "authorizationURL": "https://app.cronofy.com/oauth/authorize",
    "tokenURL": "https://api.cronofy.com/oauth/token"
  },
  "request": {
    "params": {},
    "headers": {
      "Accept": "application/json",
      "User-Agent": "Pizzly",
      "Authorization": "Bearer ${auth.accessToken}"
    },
    "baseURL": "https://api.cronofy.com/v1/"
  }
}

And here it is specified in auth:

{
  "name": "Drift",
  "auth": {
    "authorizationURL": "https://dev.drift.com/authorize",
    "tokenURL": "https://driftapi.com/oauth2/token",
    "authType": "OAUTH2",
    "tokenParams": { "grant_type": "authorization_code" },
    "authorizationParams": {},
    "auth": { "response_type": "code" }
  },
  "request": {
    "baseURL": "https://driftapi.com/",
    "headers": {
      "Accept": "application/json",
      "Authorization": "Bearer ${auth.accessToken}",
      "User-Agent": "Pizzly"
    }
  }
}

Looks like this auth property appeared after renaming of config property in scope of #49 But I still see config for example in types.d.ts which seems to be used in configuration parsing and here. It leads to state property being none, even if it is defined in custom configuration, as config property doesn't exist there. For example, in this integration:

{
  "name": "Smartsheet",
  "auth": {
    "authorizationURL": "https://app.smartsheet.com/b/authorize",
    "tokenURL": "https://api.smartsheet.com/2.0/token",
    "authType": "OAUTH2",
    "tokenParams": { "grant_type": "authorization_code" },
    "authorizationParams": {
      "state":"random123"
    },
    "auth": { "response_type": "code" }
  },
  "request": {
    "baseURL": "https://api.smartsheet.com/2.0/",
    "headers": {
      "Accept": "application/json",
      "Authorization": "Bearer ${auth.accessToken}",
      "User-Agent": "Pizzly"
    }
  }
}

I don't fully get if this auth property should be renamed back to config or eliminated at all, but looks like something should be done.

[Frenchcooc]

You're totally right @listopadiya. It's something that I've noticed with #165 as well. There's some cleanup to do with each integrations.