feat(providers): add luma-v2 targeting public-api.luma.com

[grayashh]

Problem

The luma provider targets https://api.lu.ma with verification against /public/v1/user/get-self. Luma's public API now lives at https://public-api.luma.com with routes under /v1/...: the current API reference documents only the new domain, and the conventions page describes the old routes as remaining "available for backward compatibility". We use this provider in production and override the base URL per request to reach the documented API.

Fix

Per review feedback, this adds a separate luma-v2 provider instead of changing luma in place. luma-v2 targets https://public-api.luma.com and verifies against /v1/users/get-self, the route Luma's authentication example uses. The existing luma provider is untouched, so existing connections see no change.

Included per the provider conventions (same shape as affinity-v2 and personio-v2):

• providers.yaml entry
• docs page (docs/integrations/all/luma-v2.mdx) and docs.json nav entry
• generated snippets and regenerated LLM indexes (npm run docs:generate)
• luma-v2 template logo

npm run test:providers passes.

[hassan254-prog]

Thanks for the contribution! Looking on our end, I can see there are connections that were recently created and successfully passed verification using the current verification endpoint. Would these changes introduce any breaking changes for those existing connections?
If they do, introducing a separate V2 provider would be the safest approach to ensure we don't introduce any breaking changes for existing users.

[grayashh]

I checked the three surfaces where existing connections touch this config, including the periodic re-verification (refreshConnections cron → testConnectionCredentials, which runs proxy.verification against proxy.base_url), and the change is transparent for all of them.

1. Re-verification of existing connections. Verified with a production API key that was created back when everything pointed at api.lu.ma (the same kind of credential your recently-verified connections hold):

200  public-api.luma.com/v1/users/get-self          (new verification endpoint)
200  public-api.luma.com/public/v1/user/get-self    (old path shape, new host)
200  api.lu.ma/public/v1/user/get-self              (current provider config)
404  api.lu.ma/v1/users/get-self                    (new path, OLD host)

All three 200s return the same user object, so existing keys pass verification against the new endpoint unchanged. (Nango's testCredentialsCheck only checks for a 2xx, so the response-shape difference between the old nested and new flat get-self endpoints doesn't affect verification either.)

2. Proxy calls from existing integrations. As the 200s above show, public-api.luma.com serves both route generations, including explicit /public/v1/... paths, so connections still proxying old-style paths keep working after the base_url switch. The 404 in the last line is the asymmetry motivating the PR: the new host is a superset of the old one, while the old host 404s the routes Luma's current docs describe.

3. Nothing is removed on Luma's side. Their changelog (June 2026) is explicit about the old routes: "The replaced endpoints keep working and still return their original nested shape … including the deprecated fields." I also diffed GET /public/v1/user/get-self between the two hosts with the same key: the JSON responses are identical, deprecated fields included. Existing connections get the same bytes back through the new base_url.

One correction to my own PR description: it said connections proxying explicit /public/v1/... paths would need to drop the prefix. The authenticated probe shows they don't; the new host serves that shape too. I've updated the description to match.

Given that, I don't think a separate V2 provider is needed; both verification and proxy usage stay compatible for existing connections. Happy to split it out if you'd still prefer.

[hassan254-prog]

I would recommend creating a new version of the provider instead. Existing connections created with the current base_url may be targeting different endpoints that are not covered by your tests. Changing the base_url in place could therefore introduce breaking changes for those existing connections.

[grayashh]

Done. Reworked as a separate luma-v2 provider, same shape as affinity-v2 / personio-v2: new entry targeting public-api.luma.com with verification against /v1/users/get-self, plus the docs page, nav entry, generated snippets, regenerated LLM indexes, and template logo. The existing luma provider is restored untouched, so current connections see no change at all. npm run test:providers passes locally.

[hassan254-prog]

Thanks for updating this, for the docs please use the updated folder at /api-integrations and style to write the docs for this provider.