partner-application-queue

name

partner-application-queue

description

Use this skill when an agency operator wants the list of partner applications waiting on a decision for a brand: who has applied to the programme and is sitting in the pending queue. The output is a read-only queue; the approve or decline happens in the network dashboard. How the queue is read depends on the network. Some advertiser networks expose application status through the API. Awin does not: its advertiser API returns only joined publishers with no application status, so Awin's pending queue is read from the operator's own authenticated Awin session (new UI, app.awin.com) through Claude-in-Chrome, read-only. Awin Classic (ui.awin.com) accounts have no equivalent and are detected and stopped. Trigger on: "Which partner applications are pending on Acme?", "Acme's application queue", "Who's waiting for approval on [brand]?", "Show me pending partners for Acme".

Operating instructions

You are listing the partners in one brand's application queue: relationships that are pending a decision, so the account manager knows what is waiting on them. This is the pending slice of the roster; for the full roster split and the dormant-partner worklist, use partner-roster-audit.

This skill is read-only. It lists the queue; it never approves or declines an application. To actually work through Awin's pending publishers and approve or decline them under a single human confirmation, use awin-application-auto-approval.

How the queue is read depends on the network:

• Most advertiser networks that support list_media_partners report an application status the adapter can map to pending, so the queue is read through the API.
• Awin advertiser does not. Its advertiser API endpoint (GET /advertisers/{id}/publishers/, behind affiliate_awin-advertiser_list_media_partners) returns only publishers that have already joined the programme and carries no application-status or relationship field. The adapter's status mapping therefore returns unknown for every row and a pending application never appears. Awin's pending queue lives only in the new Awin UI ("Pending partners" on the partnerships page), so it is read in the browser, read-only. Do not present the API roster as a pending queue.

Step 1 — resolve the brand

If the user did not name a brand, ask which one. Do not guess.

Call affiliate_resolve_brand. If the user named a network, pass { network: "<slug>" } to filter; otherwise call with no arguments and filter the result to the brand the user named.

The response is an array of { brand, network, networkBrandId }. Reduce it to the bindings whose brand matches the user's brand. If none remain, tell the user the brand is not registered, suggest affiliate_resolve_brand with no args to see what is, and stop.

Step 2 — check status support per network

Call affiliate_run_diagnostic for the brand's bound networks and retain the operation matrix. Call affiliate_list_networks once and retain each binding's metadata, including knownLimitations and any per-operation claim-status overrides. Partner application status is the load-bearing field here, and its coverage varies by adapter. Use the diagnostic operation support plus the metadata to decide, per binding:

• Awin advertiser: treat the API as unable to report the pending queue, for the reason above. The pending queue is read in the browser in Step 3, not through list_media_partners. Do not filter the API roster to pending and present the result as the queue: every row maps to unknown, so an API filter would always return empty and misrepresent an unreadable queue as zero pending.
• Every other network: decide from the diagnostic and metadata whether the network supports list_media_partners at all (without it there is no queue to read, so report the gap and continue); whether a pending status genuinely means "application awaiting a decision" on this network, or whether the adapter only reports a coarser status (if it cannot distinguish a pending application, say so for that binding rather than presenting an empty or inferred queue as fact); and whether the relevant operation is partial or experimental, in which case surface that caveat in the coverage notes.

Step 3 — read the queue per binding

Keep each binding's queue separate; partner ids are network-specific. If a read fails, surface the verbatim error (network, operation, message, httpStatus). Do not treat a failure as an empty queue. Continue with the remaining bindings and flag the gap.

3a — Awin advertiser (browser, new UI only, read-only)

Take the brand's networkBrandId for awin-advertiser from the Step 1 result. This is the Awin advertiser accountId (the advertiserId).

Navigate (Claude-in-Chrome) to https://app.awin.com/en/awin/advertiser/{advertiserId}/partnerships/all, using mcp__Claude_in_Chrome__navigate with that advertiserId. Dismiss the "Welcome to your new Awin" modal if it is present. Handle the cookie banner privacy-preservingly: choose Reject or decline non-essential cookies, not Accept all.

Then check the final URL. If it has redirected to ui.awin.com (Awin Classic), STOP the Awin path and record for that binding: "this account is on Awin Classic; its pending application queue is not readable here." Awin Classic has no equivalent partnerships page. Do not attempt a Classic flow.

On the new UI, read the "Pending partners" section using mcp__Claude_in_Chrome__read_page, mcp__Claude_in_Chrome__get_page_text, or mcp__Claude_in_Chrome__find. For each pending applicant, capture what the page shows: name, publisher id, website, primary promotional type, primary sector, and the Pending status. This is the Awin queue. Read only; do not click any approve, decline, or other control on the page.

3b — other advertiser networks (API)

For each non-Awin (brand, network) binding that Step 2 confirmed can report a pending application, call the roster tool and filter to the pending status. Tool names follow affiliate_<network>_list_media_partners. Pass brand exactly as it came back from affiliate_resolve_brand. Each call returns MediaPartner[] with id, name, and status. Keep only the partners whose status is pending.

For a binding where Step 2 found that pending cannot be distinguished, do not run an API filter and present it as the queue. Report it in the coverage notes as a binding whose pending queue is not API-readable.

Step 4 — present the queue

Output in this order, per network binding:

1. Brand and network, and how the queue was read (API, or browser read of the new Awin UI).
2. Pending applications: each partner by name and id, in the order they were returned. For Awin, present only what the partnerships page showed. If a source exposes nothing beyond name, id, and status, present exactly that and no more.
3. Empty queue: if a binding genuinely returns no pending partners (an API roster with no pending rows, or an Awin partnerships page with no "Pending partners"), say "no applications pending" for that binding. Distinguish this from a binding where the queue could not be read.
4. Coverage notes: any binding where the pending queue is not readable, stated plainly. This includes Awin Classic accounts, any network whose adapter cannot distinguish a pending application, and any network missing list_media_partners entirely.
5. Failures (if any): per-network verbatim error from the envelope, or the browser read failure for Awin.

End with a one-line reminder: this is a read-only queue. Approving or declining an application happens in the network dashboard, not through this skill; for Awin specifically, awin-application-auto-approval carries out the decisions under a single human confirmation.

Matter-of-fact tone, UK spelling, no hype.

Constraints

• Read-only. This skill lists the queue; it never approves or declines an application. For Awin the queue read is a browser navigation that touches no approve, decline, or other control. Do not imply a write is available.
• Awin's pending queue is not API-readable. The Awin advertiser API returns only joined publishers with no application status, so never filter affiliate_awin-advertiser_list_media_partners to pending and present the result as the queue. Read the queue from the new-UI partnerships page instead.
• Awin Classic (ui.awin.com) accounts have no partnerships page; detect the redirect and report the queue as unreadable for that binding rather than guessing.
• Never invent applications or pad the queue. An unreadable queue is "unavailable on this network", not zero pending.
• Partner status coverage varies by adapter. Where pending cannot be distinguished, report that limitation instead of guessing the queue.
• Keep each network's queue separate; do not merge partner ids across networks.