Public API and CLI now cover the whole product

New

Public API and CLI now cover the whole product

If you've been building against FirstSales from the outside, whether that's a script, an internal tool, or something you're wiring into your own stack, you now have a public API and CLI that reach every part of the product, not just a handful of endpoints.

What changed

Deals and pipelines, companies, contact 360 records, your inbox, campaigns, Learning, account settings, and Chat are all available through the public API and CLI now. Before this, parts of the product were only reachable from inside the app itself. That gap is closed: anything you can do by clicking around FirstSales, you can now do the same way with an API call or a CLI command.

Alongside the wider coverage, API keys are now scoped. Instead of a single all-or-nothing key, you can generate a key that only has access to the parts of the product it actually needs, contacts but not billing, campaigns but not settings, and so on. If you do want a key with access to everything, there's a one-click option to grant full permissions instead of toggling every scope by hand.

On the settings side, each scope has a select-all control that actually selects every permission under that scope, not just the ones visible at first glance. If you were catching this bug before by manually clicking through a long list of individual permissions, you don't need to anymore.

If you're migrating from an internal script that was patched together against whichever endpoints happened to be public before, this release is a good time to revisit it. Anything that used to require scraping a page or exporting data by hand because the object you needed wasn't exposed, a deal stage, a contact's full 360 record, a Learning profile version, is now a first-class part of the API surface, so a workaround built around a gap can likely be replaced with a direct call.

How to use it

Generate a key from your account settings, under the API keys section. When you create a new key, you'll see a list of scopes: deals, companies, contacts, inbox, campaigns, learning, settings, and Chat. Toggle on only the scopes this key needs. If a scope has sub-permissions, use the select-all control at the top of that scope to grant all of them in one click, or expand it and pick individual permissions if you want tighter control.

If you're setting up a key for something that genuinely needs full access to your workspace, like a trusted internal integration, use the one-click full-permission option instead of working through every scope by hand.

Once you have a key, use it the same way you would any API key: pass it as a bearer token on your requests to the public API, or configure it as your credential for the CLI. From there, the CLI and API expose the same objects you work with in the product: list your deals, pull a contact's full 360 record, read or update campaign settings, query your Learning writing profile, or send a message through Chat, all from outside the app.

If you're not sure where to start, the CLI is often the fastest way to explore what's available: authenticate with your key, then list the resources under each area (deals, contacts, campaigns, and so on) to see the shape of what you can query or change before you build anything more permanent against the API directly.

A typical reason to reach for this now is connecting FirstSales to a tool you already run reporting or operations through. If you keep a separate dashboard for pipeline numbers, you can pull deals and contact records on a schedule instead of exporting a CSV by hand. If you have an internal tool that owns your source of truth for company data, you can push updates into FirstSales contacts through the API instead of re-entering them in the app. And if part of your workflow depends on triggering a campaign action from somewhere else, like a form submission or a signup event in your own product, the CLI gives you a direct, scriptable way to do that instead of building a webhook relay yourself.

Worth noting for anyone maintaining older integrations: existing API keys created before this release keep working as they did. The scoping options are additive, so you're not required to reissue every key you already have; you can start using scopes and the full-permission grant only for new keys going forward, and revisit older ones on your own schedule if you want tighter control over what they can touch.

Why it matters

A public API that only covers part of a product forces you to either build brittle workarounds for the missing parts or give up on automating them at all. With the whole product reachable, you can build a real integration: sync deals into your own reporting, pull contact research into another tool, trigger campaign changes from your own workflows, without leaving gaps where you have to fall back to clicking through the UI by hand.

Scoped keys matter for a more practical reason: security. A key that can only touch contacts is a lot less risky to hand to a third-party tool or store in a script than a key with access to your billing and settings. If a scoped key leaks or gets misused, the damage is limited to what that key could actually see. The one-click full-permission option is still there for the cases where you genuinely want one key to do everything, like an internal admin tool you fully trust, but it's no longer the only option.

The select-all fix removes a small but real source of friction: setting up a new integration used to mean clicking through dozens of individual checkboxes to grant a key the access it needed within a single scope. Now one click covers the whole scope, and you can trust that it actually did.

Availability

The expanded public API and CLI coverage, scoped keys, and the one-click full-permission grant are live for all accounts with API access enabled in settings. If you don't see the API keys section under settings, check that API access is turned on for your workspace.