DIRECT ANSWER
Agencies should not borrow a client’s Scintilla login. The supplier sponsors the agency, the agency signs a Service Provider Access Agreement with Walmart, and each person receives credentials under the agency’s account. One primary client can grant full subscribed access; each additional client requires its own SPAA and exposes a limited application set.
Not by borrowing the client’s login. Walmart prohibits sharing Scintilla credentials with any third party, full stop, and it built a specific structure for firms like yours instead: sponsored access. The client, as the supplier, sponsors your firm as a third-party service provider; your firm signs a Service Provider Access Agreement (an SPAA) directly with Walmart; and once both are in place, your people are assigned their own credentials under your firm’s own Scintilla account. From there, one login per person can serve the whole client roster: full access to one primary client’s subscription, plus a limited, defined set of self-service applications for each additional client, each of those under its own SPAA. Since Walmart’s January 2026 release, the day-to-day grants also run through a self-service request flow, so your analysts request access themselves and the client’s admin approves from a queue, rather than the client keying in each person by hand. That is the Walmart-side structure as of July 2026; the screens inside Scintilla are what governs, and if what you see in the portal differs, trust the portal.
Why can’t the client just add your team under their own logins?
Because Walmart’s sharing terms for Scintilla rule it out explicitly: a supplier is prohibited from sharing its own credentials with any third party, and an outside firm receives access on three conditions. It must be sponsored by the supplier, it must sign an access agreement with Walmart directly, and it must then be assigned its own credentials.
The signature map is worth having straight before the engagement letter goes out, because two of the three signatures are not yours. The supplier sponsors; that is their act, not yours. Your firm signs the SPAA directly with Walmart; the client’s own master service agreements with Walmart continue to govern what the data may be used for. And the SPAA is per supplier relationship: when a second client wants you in their account, that client needs its own SPAA with your firm in place before their admin can grant you anything. If the engagement involves category-scope work, there is a further legal layer, the Category Advisor Agreement, which sits on top of ordinary permissions; category access is not something a role toggle alone confers.
One practical consequence for a practice: the deliverables inherit the structure. Walmart data pulled under your credentials for Client A is Client A’s engagement; the same sharing terms that prohibit credential borrowing also bar Walmart data, even masked, from moving outside the supplier organization it belongs to, and each SPAA scopes your access to that one client.
What does the provisioning actually look like, end to end?
Two accounts get built, in sequence: your firm’s own Scintilla organization first, then the grants from each supplier into it. Your side comes first because nothing can be granted to a login that does not exist.
Your firm’s account has its own miniature administration. An Agency Admin role manages your firm’s domains and users; the structural catch is that this role can create accounts but cannot grant Scintilla application access. That power stays with the client’s admin. Before your people can be added at all, your firm’s email domain has to be authorized in the account, and Walmart puts real constraints on that step: open consumer domains (Gmail, iCloud, and the like) cannot be authorized, so a contractor on a personal address needs a firm mailbox first, and an email domain registers to one company account, not several. A newly added user then sits pending until they click their activation email, which is the usual answer to “we added her but she can’t log in.”
Then the supplier side. The client’s admin has three routes to you: add your people directly through User Management, approve requests as they arrive, or proactively grant access through the 3P Partners screen, which lists the outside firms holding a signed SPAA with both Walmart and that supplier. The route that has mattered most since January 2026 is the middle one, the Account Access self-service flow: your analyst goes to Profile, then Settings, then Account Access, sees the suppliers whose SPAA with your firm is signed, selects the client, checks the applications, and supplies a role and a written reason. The reason field is required, and it is not ceremony; it is the context the client’s admin sees when your request lands in their Access Requests queue. Approval or denial comes back by email, and every request, approval, and denial is written to the account’s Activity Log, which is the record you point to when an access audit question comes up mid-engagement.
How does one login serve multiple clients?
Through a two-level structure Walmart defines: full access to one primary supplier, limited access for every additional supplier. Your analyst holds full access to one primary client’s account, meaning every Scintilla product that client subscribes to, and for any number of additional clients, access to a short, fixed list of self-service applications, Report Builder and Channel Performance Insights among them. The portal’s request screen shows the exact list; it is the same set the self-service flow covers.
Two boundaries inside that structure shape engagements. First, what “full access to the primary” means depends entirely on what the primary subscribes to: full access to a Basic client’s account is Report Builder over their own data, and the Basic versus Charter line is worth walking before the SOW is scoped. Second, Shopper Behavior is not in the self-service application set. A secondary client who needs you in Shopper Behavior is handled outside the request flow entirely, and as of July 2026 Walmart has it slated for self-service rather than in it. When you do hold Shopper Behavior across clients, the module’s Active Client switcher is how one login changes which client account it is operating against.
One more agency-specific boundary, in Customer Perception: the third-party role there can create and modify only its own research projects and cannot view others in the account. If the engagement calls for reviewing the client’s prior studies before fielding new ones, that role will not show them to you, and the viewing has to happen on the client’s side of the glass.
What are the lead times, and what expires?
Three clocks are worth planning around, current as of July 2026. First, Shopper Behavior provisioning takes up to two business days after the grant, while the other application permissions land effectively immediately; a new analyst promised into Shopper Behavior for a Monday deliverable needs the grant before Thursday. Second, a pending access request expires after sixty days if the supplier’s admin neither approves nor denies it, and it expires quietly; a request that went quiet is checked in the Requested tab, and an expired one is resolved with the client’s admin and resubmitted, not waited on. Third, the SPAA itself moves at contract speed on both Walmart’s side and yours; it is the long pole to plan first.
API and warehouse-feed access to a client’s data runs on a separate track from everything above, with its own longer clock. The supplier, not your firm, files the third-party access request, and the filing lives or dies on its business justification: who gets access, why, and at what level. Requests without that paragraph get denied; the ones that get provisioned carry it. The request routes through the client’s Walmart Data Ventures account manager, Walmart issues a consumer ID, your firm generates a keypair and hands back only the public key, and in practice this year the turnaround has run two to three weeks. The process shifts, so the client’s account manager is the source for the current form before anyone quotes an integration date.
Access also cascades on the way out. Removing a user strips Scintilla, its applications, and the Knowledge Base together, and editing an authorized domain’s settings can remove the access of users sitting on that domain. The structural point is that what a user currently holds across suppliers lives in the Active tab of User Management, and the history behind every grant, request, approval, and denial lives in the Activity Log; when an engagement’s access comes into question, those two screens, not memory, hold the answer.
What about the access question that surfaces mid-engagement?
The questions above are the ones you can schedule. The ones you cannot are the mid-engagement kind: whether a secondary client’s grant covers the module the deliverable needs, which role a new analyst should request, whether the thing that stopped working expired or was revoked. Retail Reason answers those directly, as asked, in the middle of the work: every answer carries the date it was last verified and a confidence class, so you know which facts are firm and which to re-check in the portal, and no person sits between the question and the answer. It answers questions and checks plans; it does not file anything or touch anyone’s account. See pricing, or contact Matt.