The dashboard is for judgment calls. The API is for everything else.
A real founder/ops workflow on Norbelys: the API handles bulk import and recurring automation, the dashboard handles the calls a human should make.
By Gabriel Lara, Developer Relations, Norbelys
Founder-reviewed ·How we research and correct articles
Most founders running their own outbound don’t pick “the dashboard” or “the API” as their tool — they use both, every week, without thinking of it as a choice. The actual pattern, once you watch how it plays out, is consistent: the API handles anything mechanical and repeatable, the dashboard handles anything that needs a person to actually look at it. Here’s what that split looks like in practice, not as a rule to follow but as a description of how the work already splits itself.
What a real week looks like
Monday morning, a fresh export lands from the CRM — a few hundred new leads that matched this week’s ICP criteria. This is API territory: script the same bulk-create call you ran last week, unchanged, against the new file. Nobody needs to watch this happen; it either succeeds and reports a count, or it flags rows that need attention.
Tuesday, a segment needs a human eye before it’s trusted. The “engaged but never replied” segment auto-updates with the week’s fresh activity, and before enrolling a new follow-up campaign against it, someone opens the dashboard and actually looks — does this list feel right, does the match count make sense, is there a name in here that shouldn’t be. That’s not a task an API call should be making unsupervised, and it isn’t one a script would even notice needed checking.
Wednesday through Friday, replies come in. The unibox is where every reply across every mailbox actually gets read and answered — nothing about triaging a real conversation belongs in a terminal. A person reads the reply, judges the tone, decides what to say back. That’s the dashboard’s whole reason for existing: judgment a script can’t make.
Sunday night, a scheduled job runs unattended. A small cron script checks every connected sender’s status and posts a Slack message if anything’s flagged unhealthy — nobody’s awake to click through the dashboard at 11pm, and nobody should have to be, for a check that’s the same every week.
Why this isn’t the CLI-vs-dashboard question again
This might sound like the CLI-versus-dashboard
heuristic restated, and
the underlying logic — mechanical work scripted, judgment work reviewed —
is genuinely the same one. What’s different here is the surface: a
founder building this pattern into an actual product (an internal
dashboard, a Slack bot, a nightly report) reaches for an SDK inside that
application, not a terminal command run by hand. @norbelys/sdk or the
Python package sits inside the code doing the CRM sync or the health
check; the CLI is what you’d type interactively, not what a running
service calls. Same contract underneath, different shape for a different
job — a script you type versus a script that’s already running somewhere.
The part that actually saves time
The genuine payoff of this split isn’t that scripting is impressive — it’s that the mechanical half stops competing for attention with the half that actually needs it. A founder who’s manually re-uploading the same weekly CRM export by hand is spending judgment-quality attention on a task that has none, which means less attention left over for the reply that actually needed a thoughtful answer. Automating the import doesn’t just save the ten minutes it took — it protects the hour of good judgment the rest of the week depends on.
Quick answers
Do I need to be a developer to run any of this?
The dashboard half needs none. The API half benefits from being comfortable with a script, but a founder who can write a basic cron job and call an SDK method is enough — none of this requires a dedicated engineer.
What if I only ever want to use the dashboard?
That's a completely normal way to run Norbelys, and most people do exactly that for most tasks. The API split described here is for the specific recurring tasks worth automating, not a requirement to script anything at all.
Can the API and dashboard conflict, like two people editing the same segment at once?
No — both talk to the same underlying data through the same validation, so a change made via the API shows up in the dashboard immediately and vice versa. There's no separate state to get out of sync.
Set up both, use whichever the task calls for
An API key takes a minute to generate in the dashboard, and from there every workflow above — the weekly import, the health check, the reply triage — is available the same day. Every plan starting at Starter includes the full REST API, SDKs, and dashboard with no feature gap between them, so the split described here isn’t something you grow into on a higher tier. See what’s included at each level, generate a key, and let the mechanical half of your week start running itself this week.