Gap
The Python SDK's Router.fetch_event_matches accepts a url= keyword and puts it on the wire as params["url"]. Core's FetchEventMatchesParams has no url field at all, and core's browse-vs-lookup branch only considers eventId/slug. A caller who passes only url= therefore does not get "matches for that event" — they silently fall through to browse mode and receive an unfiltered, catalog-wide list of event matches with no error. The TypeScript SDK doesn't offer url on fetchEventMatches at all (unlike its sibling fetchMarketMatches, which does), so the two SDKs disagree about whether the capability exists, and neither actually works end-to-end.
Core
core/src/router/types.ts:156-170 — FetchEventMatchesParams declares query, category, event, eventId, slug, relation, minConfidence, limit, includePrices. No url.
core/src/router/Router.ts:524: const hasIdentifier = params.eventId || params.slug; → falsy for a url-only call → routes to this.client.browseEventMatches(params) (line 526).
core/src/router/client.ts:74: const id = params.eventId ?? params.slug; — url is never read; browseEventMatches (line 109) forwards only query/category/relation/minConfidence/limit.
Core itself has to cast around its own type to reach url at all: core/src/router/Router.ts:719 — lookupString((params as FetchEventMatchesParams & { url?: string }).url), used only for local mock fixtures, not the real lookup path.
TypeScript SDK
Missing — no url on the fetchEventMatches overloads (sdks/typescript/pmxt/router.ts:327-337).
Python SDK
sdks/python/pmxt/router.py:251 (url: Optional[str] = None) and :285-286 (if url is not None: params["url"] = url) — sent to a core field that doesn't exist and isn't used for identifier resolution.
Evidence
core/src/router/types.ts has no url field on FetchEventMatchesParams; Router.ts:524 and client.ts:74 both compute the lookup identifier from eventId/slug only, never url.
Impact
Python users who hold an event URL (the natural handle when coming from a venue page) get silently wrong results — a full, unfiltered browse listing presented as "matches for their event" — with no error raised. TypeScript users can't even attempt the lookup by URL.
Found by automated Core-to-SDK surface coverage audit
Gap
The Python SDK's
Router.fetch_event_matchesaccepts aurl=keyword and puts it on the wire asparams["url"]. Core'sFetchEventMatchesParamshas nourlfield at all, and core's browse-vs-lookup branch only considerseventId/slug. A caller who passes onlyurl=therefore does not get "matches for that event" — they silently fall through to browse mode and receive an unfiltered, catalog-wide list of event matches with no error. The TypeScript SDK doesn't offerurlonfetchEventMatchesat all (unlike its siblingfetchMarketMatches, which does), so the two SDKs disagree about whether the capability exists, and neither actually works end-to-end.Core
core/src/router/types.ts:156-170—FetchEventMatchesParamsdeclaresquery, category, event, eventId, slug, relation, minConfidence, limit, includePrices. Nourl.core/src/router/Router.ts:524:const hasIdentifier = params.eventId || params.slug;→ falsy for a url-only call → routes tothis.client.browseEventMatches(params)(line 526).core/src/router/client.ts:74:const id = params.eventId ?? params.slug;—urlis never read;browseEventMatches(line 109) forwards onlyquery/category/relation/minConfidence/limit.Core itself has to cast around its own type to reach
urlat all:core/src/router/Router.ts:719—lookupString((params as FetchEventMatchesParams & { url?: string }).url), used only for local mock fixtures, not the real lookup path.TypeScript SDK
Missing — no
urlon thefetchEventMatchesoverloads (sdks/typescript/pmxt/router.ts:327-337).Python SDK
sdks/python/pmxt/router.py:251(url: Optional[str] = None) and:285-286(if url is not None: params["url"] = url) — sent to a core field that doesn't exist and isn't used for identifier resolution.Evidence
core/src/router/types.tshas nourlfield onFetchEventMatchesParams;Router.ts:524andclient.ts:74both compute the lookup identifier fromeventId/slugonly, neverurl.Impact
Python users who hold an event URL (the natural handle when coming from a venue page) get silently wrong results — a full, unfiltered browse listing presented as "matches for their event" — with no error raised. TypeScript users can't even attempt the lookup by URL.
Found by automated Core-to-SDK surface coverage audit