Connect InboxKit Mailboxes to SendKit in Under 2 Minutes

SendKit is the shortest integration in the InboxKit catalog. Instead of email + password per mailbox, or a bulk CSV upload, you paste a single SendKit API key into the InboxKit Sequencers Connect screen. InboxKit validates the key against SendKit in under a second, fetches your SendKit workspace name, and blocks the export until your SendKit workspace has Google or Microsoft OAuth credentials configured. That last part is the only common stumble, and this guide walks through exactly how to unblock it.

The whole setup takes around 90 seconds once you have the API key in your clipboard. There is no SMTP host to remember, no IMAP port, no app password, and no per-mailbox OAuth consent screen. This is the flow to use if you are running a dedicated SendKit infrastructure and want every new InboxKit mailbox to show up inside SendKit automatically.

Every other sequencer in the InboxKit Connect screen asks for an email + password (Instantly, Smartlead, Reply.io, Salesforge) or a CSV upload. SendKit is different because of three architectural choices:

The validation is specifically implemented in the InboxKit connect flow as a debounced API key check (800ms) against SendKit's verify endpoint. If the key is invalid you get an 'Invalid API Key' badge. If the key is valid but your SendKit workspace is missing OAuth credentials, you get a yellow 'OAuth setup required' warning that blocks the submit button until you fix it. Compare this to the 6-step app password flow required for Instantly and you see why SendKit users stay with SendKit.

Before you open the InboxKit Sequencers Connect screen, have these ready:

The OAuth credential trap. SendKit requires a workspace-level Google OAuth Client ID and Client Secret (plus a Microsoft equivalent if you are sending from Microsoft 365 mailboxes). This is not the same as per-mailbox OAuth. It is a set of workspace credentials that SendKit uses to impersonate the mailbox during sending. If your SendKit workspace does not have these set, InboxKit will refuse to finalize the connection and show a yellow warning card with the direct URL to the SendKit OAuth setup screen: https://app.sendkit.ai/dashboard/mailboxes?oauth-setup=true. Click that link, configure the Client ID and Secret in SendKit, then come back and retry.

Once the prerequisites are green, the actual connection is a single screen in InboxKit.

Total: about 90 seconds, start to finish.

The only screen you see is the InboxKit Sequencers Connect screen with a single API Key field, a workspace details card below it, and a Connect Account button. There is no email, no password, no SMTP server dropdown, no per-mailbox consent screen. This is intentional. SendKit handles all the per-mailbox OAuth inside its own app.

This is the warning that stops roughly 90% of first-time SendKit connections. It looks like an amber card with the text 'Your SendKit workspace needs Google/Microsoft OAuth credentials configured before mailboxes can be exported.'

Here is exactly how to unblock it:

Where the Client ID and Secret come from. Google OAuth credentials come from Google Cloud Console → APIs & Services → Credentials → Create OAuth client ID → Web application. Authorized redirect URIs must include https://app.sendkit.ai/auth/callback (SendKit's own docs list the exact URI). For Microsoft 365, go to Azure Portal → Microsoft Entra ID → App registrations → New registration and configure delegated Mail.Send and Mail.ReadWrite permissions.

The reason SendKit routes OAuth this way is that API scope review is done once per workspace instead of per mailbox. If you add 50 mailboxes, you do not approve 50 consent screens. You approve zero. That is the main speed advantage over the Instantly per-mailbox OAuth flow.

Once the OAuth warning clears and you click Connect Account, InboxKit sends SendKit the data for every mailbox in your selected export set. The payload for each mailbox looks like this:

SendKit does not receive passwords, app passwords, or refresh tokens from InboxKit. It initializes its own OAuth handshake against your workspace credentials after InboxKit hands off the mailbox identity. If you later rotate the SendKit API key in SendKit → Settings, InboxKit's background sync will start failing with 401 Unauthorized. Fix it by rotating the key in the same InboxKit connection (Sequencers → SendKit → Edit → paste new key).

SendKit ships a dedicated warmup network. InboxKit ships an isolated warmup add-on at $3 per mailbox per month. Running both at the same time on the same mailbox is a bad idea.

Pick one. Running two warmup networks on the same mailbox roughly doubles warmup-sent volume, confuses reputation signals at Gmail Postmaster, and can trigger deliverability dips. If you moved a mailbox from InboxKit warmup into SendKit warmup, turn off the InboxKit warmup subscription for that mailbox in InboxKit → Mailboxes → Warmup toggle. See the email warmup tools comparison for a deeper look at how the peer networks differ.

For domain-level setup (SPF, DKIM, DMARC), none of this changes with SendKit, since InboxKit already handles the DNS side in under 60 seconds via Cloudflare. If you are setting up a brand new domain, go through the cold email domain setup checklist once, then the SendKit connection is the last step.

These are the five specific errors the InboxKit connect flow can surface for SendKit, and exactly what to do about each:

One subtle gotcha: the API key is workspace-scoped, not user-scoped. If you generate a SendKit API key while logged in as a workspace admin but paste it while the SendKit workspace is in a 'trial expired' state, validation still passes (the key is valid) but the export will fail silently with zero mailboxes added. Check the workspace status badge in the InboxKit workspace card before hitting Connect. If it says anything other than 'active' or 'configured', fix that in SendKit first.

Do not trust the green success toast alone. Run this smoke test before launching a campaign:

Test 1, round-trip a single mailbox. In SendKit, find one of the freshly imported InboxKit mailboxes, click Send Test to your own inbox. Expected: email lands in <30 seconds, shows via sendkit.ai in the headers, and DKIM signs with your sending domain.

Test 2, inbox placement test. Send a test to a seed list (Gmail, Outlook, Yahoo, Hotmail). Aim for 9/10+. Anything below 8/10 means your DNS or warmup needs more time. See inbox placement testing explained for the full methodology.

Test 3, reply round-trip. Reply to the test email and confirm SendKit Unibox picks it up within 2 minutes. If not, the IMAP side of the workspace OAuth is misconfigured (usually a missing Mail.ReadWrite scope).

Test 4, a one-mailbox pilot campaign. Before loading the full sequence, run a 10-prospect campaign from a single InboxKit mailbox for 2 days. Check for bounces, spam complaints, and SendKit's native reputation graph. If all green, scale up. For the math on how to scale from 1 to 10,000 sends per day, see the scale cold email playbook.