feat(api): [NAN-793] bulk metadata update api

[khaliqgant]

Describe your changes

Update the set and update metadata endpoints to accept an array of connection ids. If any invalid connection is passed in at any point in the array the entire operation is bailed and no metadata is set.

Issue ticket number and link

NAN-793

Checklist before requesting a review (skip if just adding/editing APIs & templates)

• I added tests, otherwise the reason is:
• I added observability, otherwise the reason is:
• I added analytics, otherwise the reason is:

[linear]

NAN-793 Bulk metadata update API planning

[bastienbeurier]

Do we need new endpoints for this? Can we just support both a single value and an array in the existing routes?

[khaliqgant]

That what I would have liked to do but we can't without deprecating this current method. This is because the connectionId is passed as part of the URL:

curl --location --request PATCH 'http://localhost:3003/connection/to-override/metadata?provider_config_key=google-calendar' \
--header 'Content-Type: application/json' \
--data '{
    "myMetadata": "bar"
}'

[bastienbeurier]

Got it. In this case, I would aim to make this endpoint the new standard, and later deprecate the other one, so we keep a minimal number of endpoints.

In order to do so, I would remove bulk from the endpoint and have something like:
PATCH https://api.nango.dev/connection/update-metadata
POST https://api.nango.dev/connection/set-metadata

What do you think?

[TBonnin]

that's logical. It is mirroring the endpoints to modify metadata for a single connection

// single connection
POST /connection/:connectionId/metadata
PATCH /connection/:connectionId/metadata

// multiple connection
POST /connection/metadata
PATCH /connection/metadata

[bodinsamuel]

👌🏻
It would have been great to use the new pattern of creating routes, just to have some payload validation and test but not blocking

[khaliqgant]

# POST: set metadata
curl --location '/connection/metadata?provider_config_key=unauthenticated' \
--data '{
    "metadata": {
        "my_metaddata": "no"
    },
    "connection_id": ["one", "two-connections"]
}'

# PATCH update metadata
curl --location --request PATCH '/connection/metadata?provider_config_key=unauthenticated' \
--data '{
    "metadata": {
        "updated-metadata": "meta"
    },
    "connection_id": ["one"]
}'

The older metadata endpoints still exist but now exist in the documentation marked as legacy.

One more pass is requested to the interface and implementation @bastienbeurier @TBonnin @bodinsamuel

[bastienbeurier]

Same here about the query apram

[khaliqgant]

Updated

[khaliqgant]

👌🏻 It would have been great to use the new pattern of creating routes, just to have some payload validation and test but not blocking

Added with 81943a6

[TBonnin]

would have been nice to have all the queries as part of a transaction. Here we might potentially have some out of sync Metadata if one or more query fails somehow

[khaliqgant]

Updated with 25669dc