Decide before you connect anything — Another Orange Morning

If you have five minutes

The tempting order is: get the API key, wire up the connector, build the agent, worry about the marketplace later.
Seven of the twenty updates this pillar tracks are still in public or private beta, and one of them now meters against a shared credit budget the moment it runs.

1 of 4

Decide before you configure

The tempting order is: get the API key, wire up the connector, build the agent, worry about the marketplace later. Seven of the twenty updates this pillar tracks are still in public or private beta, and one of them now meters against a shared credit budget the moment it runs. Committing to that order gets the cost question backwards — you find out what something costs after it's already running. The order below starts with what's already stable and live, and treats every private-beta piece as something you scope around, not something you commit a roadmap to.

2 of 4

Five decisions, signed before you configure anything

Decision	Owner	What it costs to get it late
Which reach is read-only and which can write	Whoever owns the integration's design	An agent or connector granted write access before anyone decided it needed one
Whether a private-beta capability is load-bearing to the build	The technical lead	A roadmap built on Describe an app, deploy it to your portal, or Use Webhooks in custom agents, that has to be re-scoped when the beta changes shape
Who owns an installed app once it's live	Whoever configures Connected Apps' app-owner management	An app nobody can account for when something goes wrong with it
What the credit budget is, before an agent's tools expand	Whoever owns the HubSpot bill	An agent-run credit bill that surprises finance the same week the capability shipped
What the marketplace submission plan is, if you're publishing	Whoever owns the go-to-market for the app	Building an app, then discovering the active-install eligibility bar after the fact

3 of 4

The order things go in

Start with the read-only, live pieces. The Payments Account Public READ API and the new Account Info API fields are live, not beta, and they only read. Build the check-before-you-act logic first — is this account ready, does this integration have accurate context — before anything writes.
Treat a webhook as a notification, not a trigger for a write, until you've watched it run. Use Webhooks in custom agents is a private beta. Build the agent the same way you'd build any agent — instructions, data, context, tools — and add the webhook as one tool among several, not the mechanism the whole build depends on.
Price the agent before you expand what it can reach. Custom agents consume credits per run now, and that metering shipped the same week webhooks did. Know your credit budget before adding a tool that increases how often, or how expensively, the agent runs.
Hold app-building for after the reach is proven. Describe an app, deploy it to your portal is private beta, invite-only, and — by the account of the person who built one live on air — rough-edged. It's the right tool for turning proven CRM reach into a permanent place your team goes, not the first thing to build.
Decide the marketplace question last, and decide it as its own project. Publishing to the marketplace is a different commitment than building against the API for internal use. It has its own eligibility bar, its own review, and its own cost in relationship-building before the first install — cover that separately from the technical build.

4 of 4

What each step actually costs, in the operators' own words

The read-only check costs almost nothing, and that's the point.: Casey Hawkins and Chris Carolan, on the Payments Account Public READ API: "What to do: if you build on HubSpot payments, put this check at the front of your setup flow. If you do not, this one is safe to skip." Not every read-only API is worth building against — only the ones your build actually depends on.
The webhook-and-credit decision costs attention, not code.: Chris Carolan's take on Use Webhooks in custom agents: "Expanding what an agent can reach right as every agent run starts drawing down a shared budget means the design question is no longer just can this work, it is what does this cost each time it runs." Budget for that question before you scope the agent, not after the first invoice.
Building on the app-deployment beta costs patience, by design.: On Describe an app, deploy it to your portal, the take describes the build itself: "It is early, invite-only, and rough-edged, and it ran long enough to earn the show's first cliffhanger." If a build depends on this shipping on a schedule, that dependency is the risk to name to whoever owns the roadmap — not something to discover mid-build.
Marketplace submission costs relationships, before it costs anything technical.: Chris Carolan on the eligibility bar moving from total installs to active installs: "Getting your first three active installs means going and talking to people. I usually start with a known network that has already asked for the thing, then build from there. That part is fine and it is how it should work." Budget the outreach, not just the build, and expect the uncertified-app warning screen to be a real obstacle for your first customers, not a formality: "It reads like the highest risk activity you could possibly perform on your portal."

One honest gap

Two updates on this pillar are named sunsets — the Pipelines API v1 deprecation and the Legacy Private App Creation sunset — and neither carries a covered date or an on-air take in the archive yet. Both are real, both are upcoming per HubSpot's own status field, and neither has enough here to tell you when the door closes. If either path is load-bearing to your build, check HubSpot's own developer documentation for the sunset date before you plan around this page's silence on it.

"What to do: if you build on HubSpot payments, put this check at the front of your setup flow. If you do not, this one is safe to skip." — Casey Hawkins + Chris Carolan, Payments Account Public READ API.

"Getting your first three active installs means going and talking to people. I usually start with a known network that has already asked for the thing, then build from there. That part is fine and it is how it should work." — Chris Carolan, Improvements to Marketplace Submission Eligibility.

"It is early, invite-only, and rough-edged, and it ran long enough to earn the show's first cliffhanger." — Chris Carolan, Describe an app, deploy it to your portal.

Where to next

Where this comes from

The show's own update pages. every quote here is the take published at anotherorangemorning.com/hubspot-updates/{slug}, curled live and checked line by line on 2026-09-05
The live HubSpot Updates read, 2026-09-05. every status and first-covered date is the value on the update's own record at the time of that read, calibrated against a known-nonzero control before it was trusted
Chris's steer on this pillar, the nine-Hub walk, 2026-09-05. "Shouldn't this Hub focus on API related updates?" — read as the developer surface, with the admin, account and reporting-UI records filed under the same value treated as tagging debt rather than members

What we do not know yet

Seven of the twenty updates this pillar tracks are still in public or private beta, and one of them now meters against a shared credit budget the moment it runs.
Describe an app, deploy it to your portal is private beta, invite-only, and — by the account of the person who built one live on air — rough-edged. If a build depends on this shipping on a schedule, that dependency is the risk to name to whoever owns the roadmap — not something to discover mid-build.