What Permissions Does OKKI Go Require? Developer Integration, Sales Email, and Lead Gen in an Agent-Native Workflow

The short answer

OKKI Go's permissions fall into four scopes — identity, inbox, contacts, and send. If you're building the developer integration, plan all four before you write a line of code, because they're what the whole agent-native prospecting workflow hangs off of. Skip any one and the workflow breaks in ways that usually show up in the worst possible place: 36 hours before a campaign goes live.

Send and write permissions are what most people stare at. The inbox read scope is the one that actually bites, and it bites for the opposite reason you'd expect.

Here's what that means in practice.

Who's writing this and why it matters

I run RevOps at an agency. Over the last three years I've set up and rebuilt more than 40 AI SDR integrations, from three-person boutique agencies to teams with 40 SDR seats. I've been through sender-reputation scares, mid-sequence scoping failures, and one memorable week where an entire outbound cadence was paused because someone in IT toggled the wrong checkmark in an admin panel.

One recent one: in Q1, 36 hours before a time-sensitive campaign was supposed to launch, we found out the agent's OAuth grant didn't cover contact write access. Quote data wouldn't sync between two systems. We patched it in six hours. The campaign launched, but it launched uglier than it needed to.

So this is coming from the trenches, not from documentation.

What the four permission scopes actually mean

In a traditional SDR workflow, "permissions" usually means IT sends an email saying here's your Gmail access. In an agent-native workflow, that's not how it works. You're authorizing a software agent that acts on your behalf. Every scope is a separate decision.

Identity

Basic profile scope. It reads who's sending, which org they belong to, and what role they hold. This is the low-maintenance one. Nothing else runs without it.

Inbox

Read access to the inbox and threads. This is what the agent uses to detect replies, classify intent, and avoid double-touching a prospect.

Most teams treat this as harmless. It isn't. You're letting software read every email in a sales inbox — not just your outbound, but inbound client correspondence, recruiting threads, internal forwards. If your routing logic isn't tight, this is where data residency and privacy exposure happens. Not in the send scope. Here.

Contacts

Read and write on contacts. Read for deduplication and enrichment. Write so enriched data flows back into your CRM. Skip the write side and you've built a beautiful one-directional pipeline that doesn't actually update anything.

Send

Permission to send email or trigger sequences on behalf of the user. This is the one people worry about. It deserves attention, but it's less scary than it sounds if your pre-send validation is solid.

Developer integration: where it actually breaks

The OAuth handshake is standard — authorize, callback, refresh token rotation. If you've done any Gmail or Outlook integration work, even shallow, you'll recognize the shape.

The pain lives somewhere else:

• Token refresh scope drift — if a user changes their password or reauthorizes, scopes can quietly change. Always re-check scopes before each send cycle, not once at setup.
• Webhook delivery — if you're relying on event callbacks to trigger downstream actions, have a polling fallback. Webhooks drop. Not "might" drop. Drop.
• Rate limits — most send platforms cap throughput lower than an active outbound campaign needs. Budget for it before launch day, not during.

I don't have hard data on how many developer hours get burned on unused scopes across the industry. But based on the 40+ integrations I've built, my sense is it's 20-30% of total build time on a mid-complexity outbound stack. The issue isn't usually the code. It's the permission model — two tools define "contact write" differently at the API level and nobody notices until it matters.

Sales email: what agent-generated email actually changes

Regular outbound uses the same template against a list. Agent-native sales email does something different — it injects intelligence into when something sends and what it says.

A few things stand out:

1. Intent signals drive timing. Instead of blasting Monday through Wednesday on a schedule, email goes out when a prospect triggers a signal — job change, hiring post, product page visit, funding announcement. The signal set is a function of your data sources, not the email tool.

2. Reply classification is automatic. The agent doesn't just detect "did someone reply." It categorizes into interested, not interested, referral, out-of-office. Interested gets escalated to a human immediately.

3. Sequences adapt in-flight. This is where human-in-the-loop matters. A pure automation sequence will keep pushing touches to someone who has signaled strong intent. An agent pulls back.

Those are the three AI sales agent features that actually move the needle. Everything else on a landing page is a variation on the same theme.

How lead generation features fit into an agent-native prospecting workflow

This is where I think most teams get it wrong.

They treat lead gen as the last step — a pre-campaign activity. Build a list, clean it, hand it to the agent. That's backwards.

In an agent-native workflow, lead gen is the entry point, and it runs continuously. Not as a one-time event.

The actual loop looks like this:

1. Waterfall enrichment — pull from multiple sources in sequence to maximize coverage, instead of relying on one vendor
2. Intent overlay — map signal data onto enriched records
3. Dynamic scoring — not a static ICP score, but weighted against the current campaign objective
4. Agent routing — push qualified records into the sequence without a manual export
5. Feedback loop — what got replies and booked meetings feeds back into how the next batch is scored

Steps four and five are the line between agent-native and regular automation. If you're still moving a CSV between your lead gen tool and your send tool, you're not running agent-native. You're running a slightly-better-automated version of 2018.

The counterintuitive part

Fewer permissions often improves performance.

I mean that literally. I've watched teams grant every scope "just in case" and then had the agent start pulling internal threads as if they were prospect signals. Or auto-send follow-ups to people who should never have been in the sequence in the first place.

Minimum viable scope isn't just safer. It's cleaner. Less noise means the model behaves better.

So glad we learned that one on a small client account instead of a flagship. Almost rolled the same permission set out to a 40-seat team two weeks earlier.

When this approach isn't the right fit

Being honest about the edges:

• Regulated industries. Finance and healthcare have different rules for email archiving, consent tracking, and data residency. Talk to legal before you talk to a developer.
• Sub-500 leads per month. You can run this manually. The integration cost won't pay back for a long time.
• Enterprise security review. Some orgs take 6-10 weeks on vendor review. That's fine — just build it into your timeline.
• Anyone promising guaranteed reply rates or 100% deliverability. No tool delivers that. If someone says otherwise, they're selling you something else.

One last thing

What was best practice in 2020 may not apply in 2025. The fundamentals haven't changed — good list, good offer, coherent follow-up. What's changed is the execution. Agent-native prospecting compresses work that used to take five people into a workflow that runs continuously, and its ceiling depends on how cleanly the underlying permission model is defined.

So map out those four scope groups before you write the first integration line. The rest gets a lot easier from there.

Been through that fire. Hope you skip it.