See all services Shopify Plus Partner
Dev Dashboard Developer

Vet collaborator requests with new partner detail signals

Merchants now see partner organization tenure, registration country, sending country and active collaboration range on every new collaborator request. A practical shift in how store access gets approved.

Executive summary

What changed

Shopify has added partner organization details to new collaborator requests. The merchant reviewing a request now sees how long your organization has been on Shopify, the country where the partner account was registered, the country the request was sent from, and an approximate range of merchant stores your organization actively collaborates with. Only stores on a paid plan count toward that range, so development stores do not inflate it.

Nothing needs configuring. The details are derived automatically from your organization account and its activity. The change applies to new requests only, so collaborations a merchant has already accepted are untouched. It builds on identity verification for partners, which is optional today and becomes mandatory before sending a new collaborator request.

Why it matters

Until now, a merchant approving store access had a name and a free text message to work with. That is a thin basis for granting entry to a live storefront, and attackers have exploited the gap by impersonating known agencies. For enterprise merchants this change turns an informal trust decision into something closer to a vendor check, with four verifiable signals attached at the point of approval.

For agencies the effect cuts both ways. An established organization with long tenure and a healthy active collaboration count now carries that evidence into every request. A newer organization, or one sending requests from a country that does not match its registration, will draw more questions. Neither is a penalty, but both change how you should write the request. Access governance belongs alongside the rest of your security and compliance posture.

Role-specific impact

Use-case example

Real-world scenario

A Plus merchant with an in-house team of four and three external vendors receives roughly a dozen collaborator requests a year, and previously approved most within a day on the strength of a familiar agency name. After this change the same merchant adds a two-minute check: do the registered and sending countries match the contracted vendor, and does the active collaboration range look plausible for a firm of that size. In practice that catches the outlier, a request from an organization three months old sending from an unexpected country, which turns out to be an impersonation of a known agency. One rejected request for roughly 25 minutes of review time across the year.

Implementation checklist

  1. Complete identity verification in the Dev Dashboard for every user who sends collaborator requests.
  2. Review your organization profile so the registered country and tenure shown to merchants are accurate.
  3. Standardize a request message template naming the project, the scope of work, and a contact the merchant already knows.
  4. Request only the permission scopes the work requires, and document why each one is needed.
  5. On the merchant side, add the partner details to your access approval checklist and record the decision.
  6. Re-audit standing collaborator accounts, since accepted requests are unaffected here and may predate any verification.

FAQ

Q: Do existing collaborator accounts show these details retroactively?

A: No. The change applies to new requests only. Anything already accepted stays as it is, which is why a periodic audit of standing collaborator access is worth scheduling separately.

Q: Does a low active collaboration count count against a newer agency?

A: It is context, not a score. A specific, well scoped request with a named contact carries more weight than tenure, and identity verification is the signal that actually gates access.

Resources

Collaborator requests: information shared with merchants

Need guidance? Talk to Makro.