Daml dit if Webhooks

Questions
, ,
1

Hello all,
I was reading on the daml-dit-if library and the webhook section caught my attention. I understand that, on daml hub, the base url of the webhook will be populated by the deployed ledger’s context. My question is, how would I be able to test my webhook locally through the ddit run command?

Thank you in advance

EDIT: Additionally, I’d lime to ask, if there’s any standard documentation (ex: swagger) for the endpoints that became available as webhooks for the integration.

2

@David_Martins Each integration exposes webhook endpoints via a locally hosted http endpoint. When we run integrations within Daml Hub, we use routing rules to ensure that the integration’s endpoint is accessible through URL’s that are within the context of the enclosing ledger.

When you run integrations locally via ddit run, you don’t have the routing rules, but you do have the integration’s HTTP endpoint. There are a few log messages that describe how this endpoint is running. These are taken from an instance of the Table integration (in the Core Pack) that I just started this morning.

2022-03-22T12:13:18+0000 [INFO] (daml-dit-if) Registered hook (label: CSV Table): get '/integration/{integration_id}'
2022-03-22T12:13:18+0000 [INFO] (daml-dit-if) Registered hook (label: JSON Table): get '/integration/{integration_id}/json'
...
2022-03-22T12:13:18+0000 [INFO] (daml-dit-if) Starting web server on 8080...

These log messages show you the port, HTTP verb, and full path expression for each HTTP endpoint known to daml-dit-if

Integrations print these locally too (via ddit run), and they can be used to assemble cURL commands to access the endpoints directly:

curl http://localhost:8080/xyzzy/json

(Note that the integration ID doesn’t matter… we use the ID in Daml Hub to route the incoming requests, but running locally, the ID segment of the path is ignored.)

With respect to Swagger, we do not have direct support in the framework for automatically exposing a Swagger schema. The framework operates at the level of HTTP verbs (GET or POST) and doesn’t think in terms of schemaa. (This is a deliberate choice in order to enable integrations with services that cannot be easily modeled in those terms.) However, there is nothing that prevents the existing facilities from being used to expose a Swagger-compliant API (and also a Schema.)