feat: Update to Hookdeck Go SDK v0.0.37 and support more source verifications

[alexluong]

This PR does a few things:

1: update to Hookdeck Go SDK v0.0.37

• rename "archived" to "disabled"
• fix some small type changes from the SDK
• remove default API base URL because the API without versioning doesn't work

2: add more source verification providers

• Ebay
• Enode
• FrontApp
• Linear
• Orb
• Pylon
• Shopline
• Telnyx
• TokenIo

3: add JSON source verification support

resource "hookdeck_source_verification" "verification_example" {
  source_id = hookdeck_source.example.id
  verification = {
    json = jsonencode({
      type = "stripe"
      configs = {
        webhook_secret_key = "secret"
      }
    })
  }
}

[alexbouchardd]

@alexluong Is there a way we could auto-generate those verifications / inherit from the CLI types? The issue is that we'll be adding hundreds and it seems totally unviable to maintain them in long-term terraform without automation. In theory, the Go SDK should already be auto-updated with new verification providers.

[leggetter]

@alexbouchardd - @alexluong's suggestion as a solution here has been code generation. I'll let him explain why.

[alexluong]

Hi @alexbouchardd! In theory, yes, we just haven't explored that just yet. I mentioned this to @leggetter as potentially something I can explore as well.

It would be a generator of some sort to run whenever we want to sync the TF provider with the OpenAPI spec list of source verifications.

[alexluong]

An alternative is to deal with JSON instead of a proper schema. We lose a bit of type safety but it would be more generic and we have to rely on the user to provide a valid source provider configuration.

[alexbouchardd]

That seems like an acceptable solution in the meantime

[alexluong]

This is how the source verification works currently

resource "hookdeck_source_verification" "verification_example" {
  source_id = hookdeck_source.example.id
  verification = {
    stripe = {
      webhook_secret_key = "secret"
    }
  }
}

To support JSON, I think we can go about it in a few ways

1: Breaking change, new schema

resource "hookdeck_source_verification" "verification_example" {
  source_id = hookdeck_source.example.id
  verification = json({
    type = "stripe"
    configs = {
      webhook_secret_key = "secret"
    }
  })
}

2: Still use existing schema but with a JSON option

resource "hookdeck_source_verification" "verification_example" {
  source_id = hookdeck_source.example.id
  verification = {
    json = json({
      type = "stripe"
      configs = {
        webhook_secret_key = "secret"
      }
    })
  }
}

Option 2 is probably a bit more flexible and easier for users. Especially if we want to continue schema support in the future, this is probably a better approach.

What do you think? I can look into supporting this option if you think the DX makes sense.

[alexbouchardd]

Option #2 sounds great, it provides a escape hatch for when we haven't added the provider explicitly

[alexluong]

@alexbouchardd @leggetter Added the JSON support as mentioned above. Now this is a valid source verification configuration

resource "hookdeck_source_verification" "verification_example" {
  source_id = hookdeck_source.example.id
  verification = {
    json = jsonencode({
      type = "stripe"
      configs = {
        webhook_secret_key = "secret"
      }
    })
  }
}

This should give users enough flexibility to handle all cases if the provider hasn't been updated to support their provider just yet.

[leggetter]

@alexbouchardd @leggetter Added the JSON support as mentioned above. Now this is a valid source verification configuration

resource "hookdeck_source_verification" "verification_example" {
  source_id = hookdeck_source.example.id
  verification = {
    json = jsonencode({
      type = "stripe"
      configs = {
        webhook_secret_key = "secret"
      }
    })
  }
}

This should give users enough flexibility to handle all cases if the provider hasn't been updated to support their provider just yet.

Nice 🎉