There’s a specific kind of founder who reads “cold email platform,” opens the dashboard, clicks through the sequence builder once, and thinks: I could just write this as a script. Not out of impatience with the UI — usually the UI is fine — but because scripting is genuinely how this person prefers to work, and a dashboard is friction for anything repeatable. If that’s you, this is the case for treating Norbelys as an API with a UI attached, rather than a UI with an API attached, because that’s closer to how the product is actually built.

The dashboard is optional, not primary

Most cold-email tools are built UI-first: the dashboard is the product, and an API — if one exists at all — is a secondary integration point bolted on afterward, usually thinner than what the UI can do. Norbelys is built the other direction. Every action the dashboard performs is a call to the public /v1 REST API underneath it — the same API, the same validation, the same plan limits a script would hit. There’s no “the UI can do this but the API can’t” gap to run into six months in, because the UI has no private capabilities. That means you can genuinely run your outbound operation without opening the dashboard more than once, if that’s the workflow you want.

Three ways to script it, one contract underneath

The practical choice isn’t API-versus-nothing. It’s which of three surfaces fits how you already work, and all three trace back to the same typed contract, so switching between them later costs nothing in re-learning field names or behavior:

The REST API directly, if you want full control and don’t mind writing the HTTP calls yourself — Authorization: Bearer ak_live_... against api.norbelys.com/v1, with the OpenAPI spec as the reference for every operation.

An official SDK, if you’d rather have typed methods and pagination handled for you — @norbelys/sdk on npm, norbelys on PyPI, or the Go and Ruby packages, all generated from that same spec, so the method names and field names match the API documentation exactly.

The CLI, if the operation you’re doing is more “run this and check the output” than “wire this into an application.” norbelys login --api-key ak_live_... once, and the resource commands mirror the API one-to-one:

a solo founder's Monday

$ norbelys people bulk-create --file leads.csv412 created, 8 duplicates merged$ norbelys segments create --name "warm-q3" --filter 'engaged:true'segment created: seg_9f2k...$ norbelys programs launch prog_a91xconfirm launch? this sends real email [y/N]

None of these three is the “advanced” option and the dashboard the “simple” one. They’re just different shapes for the same underlying platform, and a solo founder can move between them freely — script the weekly list import, use the SDK inside a small internal tool, and still open the dashboard when reading a reply thread genuinely wants a screen instead of a terminal.

The default stack this replaces

If you’ve done any of your own outbound before, you probably already have a version of this stack, just built with the wrong tool underneath it — a spreadsheet as the source of truth for your list, a general-purpose sending tool bent sideways into cold outreach, some duct tape connecting whatever tracks replies to whatever tracks meetings. That stack works until it doesn’t: usually the week your list grows past what the spreadsheet can dedupe cleanly, or the week you need a sender health check you’ve been meaning to write and haven’t. Scripting against a real API that was built for this specific job — sending, verification, warmup, suppression — removes the “wrong tool bent sideways” part without removing the option to script; you’re not trading automation for a dashboard, you’re trading a fragile automation stack for a solid one.

The one-time setup, not a recurring tax

Worth being honest about the actual time cost here, since “just use the API” undersells the setup for anyone who hasn’t done it before. Creating an API key in the dashboard takes under a minute. Authenticating the CLI or an SDK against it is a single command or a few lines of client initialization. From there, the ongoing cost of using the API instead of the dashboard is roughly zero — it’s not a tax you pay every time, it’s a few minutes once, after which every future automation is cheaper to build than it would have been working around a UI. That asymmetry — small upfront cost, compounding savings after — is exactly the trade a technical founder is usually already comfortable making, because it’s the same trade involved in writing a deploy script instead of clicking through a hosting provider’s dashboard every time.

What this replaces, concretely

The realistic alternative for a technical founder isn’t “no automation” — it’s usually a pile of half-finished glue: a scheduled task that scrapes the dashboard’s export button, a Zapier chain wired around a tool that wasn’t built to be automated, a spreadsheet someone updates by hand every Monday because the platform doesn’t expose the data any other way. That glue is fragile because it’s working around the product rather than through it. Calling the actual API, with the actual validation and error messages the platform gives every caller, replaces glue with a script that fails loudly and specifically when something’s actually wrong, instead of silently when a button moved.

It’s also the only path to genuinely custom logic. A dashboard offers you the workflows its designers anticipated. A script offers you whatever workflow you can write — a nightly job that checks every active program’s bounce rate and pauses anything above a threshold before you’re awake to notice, a pre-launch check that cross-references a new segment against your suppression list before it ever reaches programs_launch, a CI-style gate that runs before a DNS change ships. None of that requires the platform to have anticipated your specific workflow. It requires the platform to expose real operations, which is a lower bar and a more durable one.

Where AI agents fit for this persona specifically

The same instinct that makes scripting appealing — reduce repeatable work to something that runs itself — extends naturally to letting an agent drive the API instead of a script you wrote by hand. The MCP server exposes the same operations the CLI and SDKs do, as tools an agent like Claude or Cursor can call directly, with the same authentication and the same guardrails. For a solo founder, that’s less “hire an ops person” and more “describe the recurring check in a sentence and let the agent run it” — a morning brief that flags anything that changed overnight, a list-hygiene pass before a send, without writing the script yourself first.

Picking a surface isn’t a permanent decision

One more thing worth saying plainly, because it removes a decision that otherwise feels bigger than it is: choosing the API, an SDK, the CLI, or the MCP server isn’t a commitment you’re stuck with. Because all four trace back to the same contract, the field names, error shapes, and behavior are identical across every one of them. Start with the CLI for the first script because it’s the fastest way to see whether the workflow you have in mind actually works, then move the logic into an SDK once it’s living inside a real application instead of a shell script. Nothing about that migration involves relearning the platform — you’re changing which client library issues the same calls, not learning a second API.

Who this isn’t for

If you’d rather have a visual sequence builder, a click-through analytics view, and a support team to call when something’s confusing, that’s a completely reasonable preference, and the dashboard is built for exactly that — this piece isn’t arguing the dashboard is worse. It’s specifically about the founders for whom clicking through six screens to do something a three-line script could do is actual friction, not a minor inconvenience. If that’s the itch, the platform is built so scratching it doesn’t require fighting an API that was never meant to carry real workloads.

Where to actually start

The developer portal is the single entry point — REST API, OpenAPI spec, all four SDKs, the CLI, and the MCP server, with authentication covered once instead of per-surface. If you want the fuller case for the CLI specifically, start there; if you’re deciding whether the generated-from-one-contract architecture is trustworthy enough to build on, that’s a separate, checkable argument. And if pricing is the remaining question before you commit to any of this, it’s here — scripted or clicked, the plan underneath is the same one.