What is an open app slot in a kit?
An open app slot is a kit naming the app surface a job needs, such as email, and letting you choose which provider fills it when you install.
Some kits pin a vendor. Others name the surface and let you supply the vendor. That second shape is an open app slot, and it is one of the more consequential decisions a kit publisher makes.
Pinned app vs open slot
| Pinned app | Open slot | |
|---|---|---|
| The kit says | "This uses Gmail" | "This needs email" |
| You choose | Nothing | Which provider fills it |
| Works if you use Outlook | No | Yes |
| Instruction can assume | That vendor's specifics | Only what the surface guarantees |
| Best for | Jobs genuinely tied to one product | Jobs about the work, not the tool |
What it looks like in the catalog
Three real kits, all with slots left open:
| Kit | Pinned | Open slot | Effect |
|---|---|---|---|
| School Email to Calendar | none | email, calendar | Works on Google or Microsoft |
| Subscription Cleaner | none | Any supported mail provider | |
| Influencer Client Email to Slack Monitor | slack | Slack is the point; the mailbox is not |
That last row is the pattern worth copying. Slack is named because posting to Slack is what the job does. Email is a slot because the job is "watch a mailbox" and it genuinely does not matter whose.
Compare Engineering Pulse, which pins GitHub and should: a kit that reads pull requests, stale branches and failing workflows is about GitHub specifically, and pretending otherwise would produce an instruction too vague to be useful.
Why a slot roughly doubles a kit's audience
The arithmetic is blunt. A kit pinned to Gmail is unusable by anyone on Outlook, which in most markets is not a small fraction. Leaving the slot open costs the publisher nothing at authoring time and removes the whole exclusion.
It also survives your own changes. A team that migrates from Google Workspace to Microsoft 365 keeps every slot-shaped kit working and loses every pinned one.
The cost is real but narrow: the instruction can only assume what the surface guarantees, not what one vendor offers. A kit relying on a Gmail-specific label behaviour cannot be slot-shaped without losing the thing it relies on.
How a slot interacts with access
A slot decides which product fills a surface. It does not decide **what the worker may do there**, which is still granted per app and per level through the app firewall.
Filling a slot with Gmail and granting Read is a different thing from filling it with Gmail and granting Write, and the kit states which level the job needs before you take it. Slots widen compatibility; they do not widen permissions.
You fill a slot from your connected apps, so the provider has to be connected first. A slot cannot conjure access to an account you never signed in to.
The failure mode: a slot that should have been pinned
Slots are not free of judgement, and the way they go wrong is subtle.
A publisher, wanting maximum reach, leaves a slot open for a surface the instruction actually depends on the specifics of. The kit installs happily on either provider and produces good output on the one it was built against and mediocre output on the other. Nothing errors, because the surface really does support both; the instruction was simply tuned for one.
The signal is a per-model style gap that is not about models at all: two installers reporting different quality, correlating with provider rather than anything else. The fix is either to pin, or to write the instruction against what the surface guarantees rather than what one product happens to do.
The reasonable objection
"If a slot means the instruction can only assume the lowest common denominator, slot-shaped kits are worse kits."
Sometimes, and it is the right trade-off to weigh rather than assume. The question is whether the job is about the work or about the tool.
"Scan school emails and create calendar events organised by child name" is about the work. Nothing in it needs Gmail rather than Outlook, and pinning would exclude half the parents who want it for no gain.
"Read pull requests, stale branches and failing workflows" is about the tool, and a version abstracted over "code hosts" would be worse at all of them. Pin it.
Most jobs about correspondence, scheduling and tasks are the first kind. Most jobs about a specific product's internals are the second.
When to pin instead
- The instruction depends on vendor specifics. Labels, custom fields, a particular API behaviour.
- The job is named after the product. A GitHub digest is a GitHub digest.
- Only one supported provider exists for that surface anyway.
- The output shape is vendor-determined, and abstracting it would make the instruction vague.
FAQ
What is an open app slot in a WorkerKit kit?
It is a kit naming the app surface a job needs, such as email or calendar, without pinning a specific provider. You choose which of your connected apps fills it when you install, so the same kit works on Google or Microsoft.
Does an open slot mean the kit gets more access?
No. A slot decides which product fills a surface; access is still granted per app and per level, Off, Read or Write, through the app firewall. The kit states the level it needs before you take it.
Can I fill a slot with a provider I have not connected?
No. Slots are filled from accounts you have already connected, so the provider has to be signed in first on the Connected apps page.
Should my kit use slots or pin a provider?
Ask whether the job is about the work or about the tool. Correspondence, scheduling and task jobs are usually slot-shaped and reach roughly twice the audience. Jobs about one product's internals, like a GitHub digest, should pin, because abstracting them makes the instruction too vague to be good.
What happens to a slot-shaped kit if I change email providers?
It keeps working: you fill the slot with the new provider. Kits pinned to the old vendor would need replacing, which is one of the quieter arguments for slots when you author a kit.