okki-go Integration Checklist: Permissions, Sales Email, and Agent-Native Prospecting

Who this checklist is for, and how long it takes

This is for the person wiring okki-go into an outbound stack that already exists. Usually that's a RevOps engineer, a sales ops lead, or the one SDR on the team who "knows APIs" and got voluntold.

Six steps. If your CRM data is clean, it's a 40-minute job. If it isn't, budget an afternoon. What this checklist won't fix: bad lead lists, a product nobody wants, or a sending domain that's already burned. Those are upstream problems and no integration cleans them up.

Quick context on where the list comes from. I'm a RevOps engineer handling CRM and sales-tooling integrations for six years. I've personally made (and documented) nine significant integration mistakes, totaling roughly $40,000 in wasted budget and lost pipeline. I keep this in front of me so the next person doesn't repeat them.

Step 1: Map what the agent actually does before you open the API docs

From the outside, an okki-go integration looks like "paste an API key, turn on enrichment, start sending." The reality is that the permission model you choose in step 2 is decided by decisions you haven't made yet in step 1. Skip this and you'll over-scope, which is the single most common reason an integration gets killed in security review.

Write down the three to five concrete actions your AI sales agent needs to perform. Not features — actions. For most teams it lands somewhere around:

• Pull a target account list based on an intent signal
• Enrich and verify the contacts on that list
• Draft and send a first-touch email from a rep's mailbox
• Log the reply back to the CRM and stop the sequence

Checkpoint: every action should map to exactly one system. If "enrich contacts" touches okki-go, your CRM, and a spreadsheet someone emails you on Mondays, that's not an integration problem — that's a process problem wearing an integration costume.

Step 2: Work out which permissions okki-go actually requires

This is the step people rush, and it's the one that costs the most when it's wrong.

okki-go's OAuth scopes fall into four functional buckets. Verify the exact scope strings in your developer console before you hard-code anything — vendor scope names tend to get renamed more often than the docs page gets updated.

1. Account and identity read. Nothing works without it. This is the one you can't trim.
2. Contact and company data read. Needed for enrichment and dedupe.
3. Contact, company, and sequence write. Only if your agent is modifying records or building sequences. If it's read-only, don't grant it.
4. Sales email send and engagement read. This is the dangerous one. It touches real inboxes.

Four buckets. Not fourteen. If your consent screen asks for substantially more than that, it's a red flag worth stopping on.

The governing principle here is the one in IETF RFC 6749 (the OAuth 2.0 spec): access tokens should be limited to the minimum scope the client needs, and no more. That's not a suggestion. It's the difference between a compromised token exposing your contact list versus your contact list and your ability to send email as 40 reps.

The mistake that cost us $18,000: in November 2023 I granted a full-send scope to a test integration on our primary sending domain because it was the fastest path to "does this thing work." The integration had a loop bug. It sent the same 1,400-contact sequence three times. We spent six weeks rebuilding domain reputation, and the domain never fully recovered — we eventually moved outbound to a subdomain and ate the ramp-up period again.

It's tempting to think scope is an admin checkbox. But scope is the blast radius, and you write it before you know how bad the blast is.

Checkpoint: for every scope you request, write one sentence explaining why the agent needs it. If you can't write the sentence without using the word "might," delete the scope.

Step 3: Wire sales email on a separate subdomain — no exceptions

Sales email is where okki-go stops being a data tool and starts touching revenue. Treat it accordingly.

Before connecting a single mailbox:

• Send outbound from a subdomain (e.g., go.yourdomain.com), never the root domain. Your root domain carries invoices, password resets, and customer support. Don't put a cold sequence anywhere near it.
• Set SPF, DKIM, and DMARC on the subdomain. Per DMARC.org, start with p=none so you're monitoring without blocking legitimate mail (policy guidance as of January 2025; check dmarc.org for current recommendations).
• Cap per-mailbox sends well below the provider ceiling. The platform won't stop you from looking like a spammer. That's your job.

Checkpoint: send five test emails to seed inboxes (Gmail, Outlook, and one corporate filter) and confirm they land in the primary tab before your agent sends anything real. This takes 20 minutes and has saved me more than any other step on this list.

Step 4: Where lead generation features actually fit in an agent-native workflow

People assume lead generation is a step that feeds the workflow. What they don't see is that in an agent-native setup, lead gen is the workflow — the agent is continuously re-deciding who's worth contacting, not working through a frozen list.

The sequence that's held up for us:

Intent signal → waterfall enrichment → verification → human-in-the-loop outreach.

Each link matters, and the order isn't negotiable:

• Intent first. A static list decays fast. Intent data tells the agent which accounts to prioritize this week.
• Waterfall enrichment second. No single provider covers everything. In Q1 2024 we tested four enrichment sources against the same 500-account sample and found match-rate differences of roughly 30 percentage points between the best and worst performer. Waterfalling — falling through providers until you get a hit — is the only way to close that gap.
• Verification third, immediately before send. Not at list-build time. Emails decay between build and send, and verifying early is how you end up with a 12% bounce rate on a list you already paid for.
• Human-in-the-loop last. The agent drafts, the rep approves. This is the part teams skip because it feels slow. It's also the part that keeps you out of a deliverability hole.

Checkpoint: every contact in a sequence should have a traceable line back to the signal that triggered it. If you can't answer "why is this person in here?" in one click, your agent is guessing.

Step 5: Dry-run in sandbox with hard caps

The upside of a fast rollout is obvious. The risk is that "it worked in sandbox with 10 records" is not evidence that it works with 10,000. I kept asking myself after the November 2023 incident: is saving two weeks worth potentially losing a domain I spent four years building? The answer was no, and I learned it the expensive way.

Set hard caps before the first live run, and set them in the platform, not in your head:

• Maximum sends per mailbox per day
• Maximum enrichment credits consumed per day
• Maximum records the agent can write back to the CRM per hour

Checkpoint: run the full sequence end-to-end on 25 real internal addresses first — your own team, your own CRM, your own reporting. If the data doesn't land correctly in the CRM, it isn't an email problem, and you'll find that out for free instead of after 2,000 sends.

Step 6: Build reconciliation and a kill switch before launch, not after

Reconciliation is the step nobody budgets for and everybody needs. Once the agent is running, you have three sources of truth — okki-go, the sending platform, and the CRM — and they will drift.

I still kick myself for shipping that first integration without a daily reconciliation job. If I'd built it up front, I'd have caught the send loop on day one instead of day three.

Two things to have in place on launch day:

1. A daily diff. Contacts created vs. contacts logged vs. emails sent. A mismatch above 2% means something is dropping records silently.
2. A kill switch you can hit in under 10 minutes. Not a ticket. Not a Slack message to the vendor. A button, or a documented revoke-token procedure someone can execute at 2 a.m. without you.

Checkpoint: have someone other than you run the kill switch during the dry run. If they can't, it isn't a kill switch.

Common mistakes worth avoiding

Sending from the root domain. This is the deal-breaker. Everything else on this list is recoverable. Root-domain damage takes months.

Granting broad scope to "get it working." Narrow scope slows down step 2 by maybe 20 minutes and saves you from step 2 hindsight.

Treating intent data as a lead list. Intent tells you who's showing interest. It doesn't tell you who's a good fit. Combine it with firmographics or your agent will confidently email a lot of wrong people.

Skipping verification at send time. Verifying once at list build feels efficient. It isn't. Bounce rates creep up quietly and by the time you notice, the damage is already in your sender reputation.

No reconciliation job. Without it, the first sign of a problem is a rep asking why an account got three identical emails. By then you're in cleanup mode.

Launching without a rollback plan because the deadline is close. If timing is tight, buy certainty rather than speed — schedule the vendor's support engineer ahead of the cutover date, or pay for the sandbox tier that gives you a proper staging environment. In March 2024 we paid roughly $400 extra to have an implementation engineer on call for a cutover weekend. The alternative was missing a client onboarding date that was worth considerably more than $400. Fast and unverified is the most expensive option on the menu. "Probably on time" is a bigger risk than "definitely late."

Pricing and policy details referenced above are for general guidance only. Verify current okki-go scope definitions in your developer console, and confirm email authentication requirements against the current DMARC.org guidance before you configure a sending domain.