What "there is an API" usually turns out to mean
A run of material published in February 2026 sits behind the question of whether a system has an API. Salesforce shipped API version 66.0 with its Spring '26 release, Xero's new developer tiers are due to start in March, and Anthropic released two models that bear on the steps no API covers. Read together they make the point we end up making in every scoping conversation, which is that the distance between an API existing and an API being usable on the licence a particular client holds is where most of the work goes.
When we scope a rebuild, we put that question to each system in turn, and the answer is nearly always yes, because someone has seen the vendor's developer portal. Establishing whether it is usable takes another five or six questions: whether endpoints exist for every step the process performs, whether the licence permits the call volume, and whether the client can get credentials a scheduled job can use. We ask all of them before anything gets priced.
The first thing we check is whether the API is documented. A documented API has published request and response schemas, a version number, a deprecation policy and a support channel. An undocumented endpoint is whatever the vendor's own web client calls, found in the browser network tab. Those endpoints often work well, and they carry no deprecation policy and no change notification, so any vendor release can break them. We treat them as UI automation with a different transport and rank them alongside fragile UiPath selectors.
A documented API can still change under a working integration, so the versioning policy is the next thing we read. Salesforce's Spring '26 release carried API version 66.0, and Salesforce has discontinued automatic redirection for legacy and instance-specific hostnames, so an integration still pointing at an old instance URL now fails until it is moved to a My Domain URL. Every design document we write names the API version it targets and where the vendor publishes end-of-life notices.
What the licence tier includes
An API can be fully documented and still be unavailable on the licence the client holds. Salesforce publishes its allocation as a formula. Enterprise Edition orgs get a base of 100,000 calls per 24 hours plus 1,000 calls for each Salesforce or Salesforce Platform licence, and Unlimited and Performance Editions get the same base with 5,000 calls per licence. Lightning Platform One App licences add 200 calls each, and purchased add-on capacity adds to the total. Professional Edition needs API access enabled before any of that applies.
In Australian operations work the same problem usually arrives through Xero. Xero announced in December 2025 that it was retiring the App Store revenue share model and moving developers onto five tiers from March 2026, priced by connection count and API usage. Rate limits sit at 5,000 calls per day per organisation on every tier except Starter, which gets 1,000. Egress is metered, with monthly allowances from 10 GB on the Core tier up to 250 GB on Advanced and overage charged per excess gigabyte.
Both of these change how a rebuild has to be sized, and metered egress is the part we think the industry has not caught up with. A nightly reconciliation that pulls every invoice and filters the results in Python is cheap to run against an on-premises database. The same design against a metered API consumes egress allowance every night and can attract a per-gigabyte charge. We size call volume and byte volume during the assessment, using transaction counts from the existing process logs.
Rate limits, quotas and metered egress
Rate limits come in several shapes. Per-second caps constrain burst behaviour, daily caps constrain total volume, and concurrency caps constrain how many requests can be open at once. Vendors also differ in what the cap applies to: some meter per organisation, some per connected app and some per user token, which determines whether a second service account gives the workflow any extra headroom.
Reading the remaining allowance at runtime is inconsistent. Some vendors return an X-RateLimit-Remaining header and a reset timestamp on every response, some return nothing until an HTTP 429 with Retry-After, and some return 429 with no guidance. We do not trust a documented limit until the headers have come back on a live call against the client's own tenant. We write a small client per vendor that reads whatever headers exist, backs off on 429, and records consumption to the run log so the daily budget is observable while the workflow runs.
Migration load is the case we see missed most often when people scope this work. Steady state for a rebuilt process usually sits well under the daily ceiling, and the initial backfill of several years of history can exceed that ceiling many times over. We plan the backfill as its own throttled job across several nights, and on a metered platform we put its egress cost in the project budget rather than discovering it after go-live.
Authentication models and who the automation acts as
The authentication model determines the identity the automation runs as, and that has operational consequences for the client. The OAuth 2.0 authorisation code flow ties the integration to a named person's consent and their permission set, so the workflow stops when that person leaves or their access changes. Client credentials and JWT bearer flows tie it to a service account, which is what scheduled work needs, and plenty of SaaS products either do not offer that or place it behind a higher tier. We call that a product gap, because it pushes buyers towards a worse design for reasons that have nothing to do with engineering.
Most of the detail that breaks a deployment sits in the settings around the flow: token lifetime, whether refresh tokens rotate, whether the vendor supports IP allowlisting, whether mutual TLS is required, and whether the client's own conditional access policies will block a headless process. We confirm each of these against the client's tenant configuration, since vendor documentation describes what the platform supports and the client's own settings can restrict it further.
Agent tooling uses the same authorisation machinery, which is one of the few reassuring things about the current state of it. The Model Context Protocol revision published on 25 November 2025 enhanced authorisation server discovery with OpenID Connect Discovery 1.0, aligned OAuth 2.0 protected resource metadata discovery with RFC 9728, and made OAuth Client ID Metadata Documents a recommended mechanism for client registration.
Sandboxes and the check we run before scoping
Sandbox availability varies widely between vendors. A Salesforce full sandbox is allocated 5,000,000 API calls per 24 hours, which is enough to load test a backfill. Many mid-market products offer a developer tenant with a handful of demo records and no way to load representative volumes, and some offer nothing beyond the production tenant. There is no reliable way to load test a backfill against a production-only tenant, and we say so during scoping rather than pricing the risk away.
The check itself is run per system, with credentials in hand. We call every endpoint the process needs, covering reads, creates and updates, and we record status codes, response times and every rate limit header returned. We confirm that the write endpoints are idempotent, or that an external key can make them so. We get the licence entitlement confirmed in writing by whoever owns the vendor relationship.
Where the API does not cover a step, we record that and keep the existing UI automation for it. Anthropic shipped Claude Opus 4.6 on 5 February with context compaction for long agentic runs, then Claude Sonnet 4.6 on 17 February with improvements to computer use. Anthropic reported that early users were seeing human-level capability on tasks such as filling out a multi-step web form, and said in the same release that the model still lags behind the most skilled humans at using computers. Those two statements sit awkwardly beside each other, and neither supports a prediction about what the model does on a particular client's screen. Our reading is that an unavoidable UI step is more workable to build than it was, and that the step still has no published version or support boundary, so we keep API calls for every step where an API covers the work.
UiPath's February 2026 platform release notes list Integration Service updates on 13 and 23 February, alongside Orchestrator and Agents releases in the same month, which puts connector and API surface work next to the agent runtime. When we rank an estate for rebuild order, we score each process on whether every system it touches has a documented API available on the licence the client already holds. That score goes into the roadmap alongside volume and error rate figures from the process logs.
The item we are carrying into March 2026 is what the Xero tiers do to jobs that were designed when egress was free. A nightly job that pulls a full invoice list and filters locally was a reasonable design on an unmetered connection. Whether that job breaches the 10 GB Core allowance in its first month or sits under it for a year depends on byte volume most teams have never measured, and we will not guess at the figure for any specific job before measuring it.