Getting supplier credentials through Scout

Most distributors do not have PromoStandards credentials sitting in a drawer. Getting them is a human process, supplier by supplier: some issue an integration key from a portal, others want a request sent to an integration contact. Scout can run that process on your behalf as a PromoStandards Service Provider, under an authorization the workspace Owner signs inside Scout.

The honest status, first

There is a current hold on the outbound part of this program. The authorization step inside Scout is a placeholder while its wording is finalized, and Scout's automatic supplier delivery is switched off. Recording Ask Scout to request credentials logs your intent — it does not mean an email was sent. Scout must have the approved authorization in place and release the fulfilment process before it will contact a supplier for you.

The placeholder says so on the screen: this acknowledgment only records your interest in the program; it is not a signed authorization, and Scout will not send a supplier request on it. You can keep using an available shared feed while that is resolved.

How the intended journey works

  1. The workspace Owner authorizes the request.
  2. Scout verifies the supplier's contact and requests the supported read services.
  3. The supplier provides credentials through an approved secure process.
  4. You enter them in the setup sheet and Scout checks each service — see Adding your own supplier account.

Start a request

  1. Open Connections → PromoStandards.
  2. Open the supplier. On the setup sheet, choose Ask them for credentials; from the Overview sheet the button reads Ask for credentials, or Resend request if one already exists.
  3. The request sheet opens, headed Scout is on it. — "Asking [supplier] for your PromoStandards credentials".
  4. Read THE EMAIL SCOUT SENDS. The exact text is shown to you, naming your workspace, your account number if you gave one, and the services being requested.
  5. Check Send to. This is the supplier's published integration contact. If it is missing or looks wrong, ask Scout to verify it. Do not guess an email address — Scout never guesses one either.
  6. Add or confirm the Account number if you have one.
  7. Choose the Request path:
    • Supplier contact — use the supplier's published integration contact or contact form. If no address is listed, confirm it with the supplier.
    • OneSource — for suppliers hosted there, you create your read-services API key in your own OneSource account and then choose to request order-services credentials for that supplier. You operate the portal; Scout prepares the request text. Do not paste a key into the request.
  8. Read the authorization panel — Letter of Authorization · placeholder — and its acknowledgment: "I understand this is a placeholder and supplier delivery is on hold."
  9. Record the request. Scout confirms "Saved. Scout has not sent an email."

If you would rather ask yourself

Some distributors prefer to handle their own supplier relationships. The sheet supports that:

  • Copy the email — copies the exact text. Scout confirms "Copied the exact email. Nothing has been sent."
  • Open in your mail app — opens a draft in your own mail program. Opening a draft is not sending it. Scout cannot send from your mailbox: mail connections are read-only capture grants and are never reused to send anything.
  • I sent this email myself — mark it sent, but only after you really have sent it through a process you are authorized to use. Scout records "Marked sent by you. Scout did not send an email."

If the supplier insists on its own portal, you operate your portal account yourself.

The six request states

State What it means
Requested The request has been logged. Not necessarily sent.
Sent Sending has been explicitly recorded. Credentials may still be pending.
Received Credentials are available for the service checks — not yet verified.
Verified Every service requested has answered under the current credential evidence.
Failed One or more checks need attention. Read the service-specific reason.
Withdrawn The request is no longer being pursued. This is separate from disconnecting a supplier you already have.

Each request also carries a next-follow-up date, and under Manage request you can Resend request, Withdraw request or revoke the acknowledgment you gave.

Good to know

  • Requests are never sent from your own mailbox. Your mail grants are read-only; the request is Scout's own action, or yours, and never Scout acting as you.
  • The Owner sees a periodic coverage summary listing the open requests and where each one stands.
  • Credentials never arrive in your Scout Inbox. When they arrive, type them into the setup sheet. Never email a password to Scout or paste one into a ticket or a chat.
  • "Received" is not "working". Only the per-service checks establish that, which is why the state after Received is Verified or Failed rather than Connected.
  • While you wait, an available shared feed gives you catalogue coverage — see Adding a supplier on the shared feed.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us