New Adapter: Matterfull - Xeworks alias

[And-Rud]

Docs: prebid/prebid.github.io#6641

[przemkaczmarek]

works:

[przemkaczmarek]

waiting for response

[przemkaczmarek]

verified:

[postindustria-code]

Heads-up on a file collision with another open PR, plus maintainer guidance on how to resolve it.

#4343 "New Adapter: Matterfull" (open since 2025-05-19, APPROVED, MERGEABLE) adds the very same file this PR adds — static/bidder-info/matterfull.yaml — but as a full standalone adapter (adapters/matterfull/*, openrtb_ext/imp_matterfull.go, static/bidder-params/matterfull.json, registration in openrtb_ext/bidders.go and exchange/adapter_builders.go). It is currently held only by an unrelated CI issue (semgrep-check, fix pending in #4894), so it can merge at any time.

This is more than a git conflict — the two define incompatible publisher-param contracts under one bidder code:

	#4343 (standalone adapter)	#4835 (this PR, xeworks alias)
Required params	pid only, minLength: 20	env and pid (inherited from static/bidder-params/xeworks.json)
Endpoint	https://prebid.matterfull.co/?uqhash={{.PublisherID}}	https://rtb.mtflll.com?pid={{.SourceId}}&host={{.Host}}&pbs=1
Maintainer	prebid_support@bematterfull.com	adops@bematterfull.com
Capabilities	site + app: banner, video	inherited from xeworks: banner, video, native

Whichever merges second either conflicts or silently redefines imp.ext.matterfull for publishers already configured against the first.

I raised this with @bsardo. The guidance: assuming both integrations belong to the same company, having a standalone adapter and an alias of a white-label solution such as xeworks is fine — there is precedent for exactly this arrangement, including different params and endpoints — but they need to be two separate YAML files. Since #4343 is the older, complete and already-approved PR, it will claim matterfull.yaml, so this alias needs to pick another bidder code.

Suggested next steps:

1. Rename static/bidder-info/matterfull.yaml to a different bidder code. Please note the constraint from add-new-bidder-go: "The alias name must be unique for the first 6 chars as noted above for biddercodes." — so the new name has to differ from matterfull within its first six characters, not just by a suffix. The rest of the xeworks alias family already follows this by using distinct brand names — adipolo, connektai, robustApps, and slikk in the open New Adapter: Slikk - Xeworks alias #4873.
2. Docs. #6641 currently modifies dev-docs/bidders/matterfull.md, which New Adapter: Matterfull RTB #4343's docs PR (#6042) also targets. After the rename, this alias needs its own page dev-docs/bidders/<newname>.md with biddercode: <newname> and pbs: true. The params table in #6641 is already correct — it documents the inherited pid + env, which is exactly right for an alias — it just needs to live on the new page. adipolo.md is a good template — same parent, same author, with separate Prebid.js Bid params and Prebid Server Bid Params sections; all three merged xeworks aliases (adipolo, connektai, robustApps) have their own page.
3. The PR description is empty. Please link the docs PR there (a documentation PR link is required before merge) and add a line about the relationship to New Adapter: Matterfull RTB #4343.

One minor point, no action needed if it is intentional: no gvlVendorID is declared. Aliases never inherit the parent's GVL ID (config/bidderinfo.go:371-373 — "not safe for legal reasons"), so as written this alias runs without an IAB vendor ID. If it does mean to claim GDPR support, the docs entry needs to list the main adapter's GVL ID with the company name in parentheses (see the aliasCode note in add-new-bidder-go). Flagging only to confirm the current state is deliberate.

Otherwise the alias itself is well-formed: byte-for-byte consistent with the xeworks alias family, build and ./config/... ./openrtb_ext/... tests pass, and the endpoint is live (POST https://rtb.mtflll.com?pid=1&host=x&pbs=1 -> 204).

[postindustria-code]

Update — please hold off on renaming. The premise of my earlier comment no longer holds.

The author of #4343 has taken the other route: they renamed their standalone adapter to matterfullrtb (commit 2cf277f29) and confirmed it is a separately provisioned integration. That frees the matterfull bidder code, so this alias can keep the name it already has and no change is needed here on that account.

That is also the better end state, for a reason that only became clear while checking: the merged Prebid.js matterfull adapter (modules/matterfullBidAdapter.ts) is built on libraries/xeUtils and requires pid and env — exactly the parameter contract this alias inherits from xeworks. So client and server now agree under the matterfull code, which is what the guide asks for:

If you have a client-side adapter, all parameters (including biddercodes and aliases) must be consistent between your client- and server-side adapters.
— add-new-bidder-go

Consequences for this PR:

• The rename ask is withdrawn. static/bidder-info/matterfull.yaml can stay as it is.
• Docs PR #6641 is now correct as written — modifying the existing dev-docs/bidders/matterfull.md and adding a Prebid Server Bid Params table with pid + env is the right shape, since that page documents the matterfull biddercode for both Prebid.js and Prebid Server. No new page needed. Please just link it from the PR description.
• Still open from my first comment: the PR description is empty (the docs-PR link belongs there), and gvlVendorID is absent — the latter is consistent with the rest of the xeworks alias family and needs only a confirmation that no IAB registration is being claimed.

One heads-up for maintainers rather than for the author: matterfullrtb and matterfull share their first six characters, which the alias guidance asks to avoid. There is ample precedent in master for pairs like this (adkernel/adkernelAdn, admatic/admaticde, copper6/copper6ssp), so I do not think it blocks anything — flagging it so it is a decision rather than an oversight.

Apologies for the churn on the naming question.

[postindustria-code]

@And-Rud
Do not forget upgrade your branch:

This branch is out-of-date with the base branch

[And-Rud]

@postindustria-code
Confirmed, gvlVendorID is intentionally absent — not claiming IAB GVL/TCF registration for this alias, same as our other xeworks aliases.

[postindustria-code]

Thanks — that settles it, and it is consistent with the rest of the PR: no gvlVendorID in the yaml and tcfeu_supported: false on the docs page in prebid/prebid.github.io#6641 say the same thing, so nothing is out of sync. Matches the other xeworks aliases as you say.

Nothing further from me — this is approved and mergeable.