SaaSCron: SaaS Operations

SaaS for MSPs: managing client tenants, security and backup

Ricardo Machado — Thu, 29 Oct 2026 16:00:00 GMT

You run IT for twenty small businesses, or you are about to hire a firm that does. Each client has its own Microsoft 365 or Google Workspace, its own admins, and its own idea of who is responsible when files disappear. You need a way to manage all of them without holding a master key to everything, and a clear answer on backup.

A managed service provider (MSP) is a company paid to run another company’s IT. With SaaS, the vendor runs the software, as explained in What is SaaS?. Configuration, access, security settings and backup still need an owner, and for many small businesses that owner is an MSP.

MSP work in plain terms

Think of a property manager who looks after fifty apartments. A careful one holds a separate key for each apartment, only for the rooms it services, and logs every visit. A careless one carries one master key to the whole building. Both can fix a leaking tap. Only one of them is a disaster if the keys are stolen.

Two terms do most of the work:

Tenant: one client’s instance of a SaaS service, with its own users, settings and data. In Microsoft 365, each client organization is a tenant.
Delegated administration: admin rights that a client grants to a partner, so the partner can manage the client’s tenant without a user account inside it.

Access: separate, limited keys per client

Microsoft’s answer to the master-key problem is granular delegated admin privileges (GDAP). Microsoft describes it as least-privileged access that is “granular and time-bound”, and customers “must explicitly grant” it. Partners who manage Azure no longer receive the Global Admin role on a customer’s tenant by default. Roles are assigned through security groups, with a limit of 100 security groups per customer.

In practice, that means a help-desk technician gets a role that can reset passwords, and only the senior engineer gets a role that can change security policy. Each client grants access to the partner separately, so a compromise at one client does not open all of them.

One console for many tenants

Managing fifty tenants one admin portal at a time does not scale. Microsoft 365 Lighthouse is Microsoft’s multi-tenant console for MSPs. Its documentation lists multi-tenant views across customer environments, a default security baseline for small and medium-sized business tenants, multifactor authentication and self-service password reset setup, and alerts on risky sign-ins. Microsoft says there is no additional cost to use it. It is available to partners in the Cloud Solution Provider program, both direct-bill partners and indirect resellers, and both partner and customer tenants must meet its requirements.

Third-party tools cover the same ground across more vendors: multi-tenant management consoles, remote monitoring tools, ticketing and billing systems, and SaaS security posture tools, covered in SSPM explained. This guide does not rank them.

Backup: what the vendor keeps, and what it does not

The most common client question after an incident is “can you get it back?” The answer depends on what was set up before the incident.

Microsoft 365. Microsoft 365 Backup protects SharePoint sites, OneDrive accounts and Exchange mailboxes. It costs $0.15 per GB per month for all protected data, and restores are free. The recovery window is set per backup policy: 3 months, 6 months, 1 year or 2 years. It is billed pay-as-you-go, by consumption, not per user. Partner backup applications can also be built on the same storage platform; in that case the partner’s application manages and bills it.

Google Workspace. Google Vault handles retention, legal holds and eDiscovery search and export. Google’s overview says “Vault isn’t a data archive”, and that “Vault doesn’t retain data until you set up retention rules.” Retention keeps deleted data available to search and export. It is not the same as restoring a user’s files to where they were.

For the edition and seat details of each suite, see Microsoft 365 as SaaS and Google Workspace as SaaS.

Who does what

The table sets out a common split of duties. The middle column describes the vendor’s tools named above; the right column is a starting point for your contract, not a rule from any vendor.

Area	What the SaaS vendor provides	What the MSP usually takes on	Evidence to keep
Admin access	Delegated admin roles (GDAP in Microsoft’s partner program)	Role design per client, quarterly access review	List of active relationships and roles per client
Security settings	Baselines and alerts (Lighthouse’s SMB baseline, risky sign-in views)	MFA rollout, alert response, exceptions	Baseline status report per client
Backup	Microsoft 365 Backup (paid per GB); Vault retention rules (Google)	Policies, retention choices, restore tests	Restore test log with dates and times
Billing	Per-user subscriptions; per-GB backup charges	Resale, pass-through or bundling	Monthly reconciliation of vendor bills to client invoices

Worked example: backup inside a flat per-user fee

Example: a labeled hypothetical that uses Microsoft’s published backup price. A client has 40 users and 2.5 TB of data across SharePoint, OneDrive and Exchange. You charge a flat $60 per user a month for managed services and want to include backup. Assume 1 TB = 1,000 GB.

Backup cost today: 2,500 GB x $0.15 = $375 a month.
Your fee: 40 x $60 = $2,400 a month.
Backup per user: $375 / 40 = $9.38, or $9.38 / $60 = 15.6% of the fee.

Now suppose the client’s data grows 3% a month.

After 12 months: 2,500 x 1.03^12 = 2,500 x 1.4258 = 3,564 GB.
Backup cost: 3,564 x $0.15 = $534.60 a month.
Per user: $534.60 / 40 = $13.37, or 22.3% of the same $60 fee.

The fee did not move, the headcount did not move, and backup grew from 15.6% to 22.3% of your revenue from the client. A per-GB cost inside a per-user price shifts the growth risk onto you. Pass it through at cost, or include a storage allowance and bill above it.

Checklist for each new client

Set up delegated access with the narrowest roles that cover the contract.
Remove any shared or legacy global admin accounts.
Apply a security baseline and record what is excluded and why.
Decide on backup in writing: which services, which recovery window, who pays.
Run a test restore in the first month and log how long it took.
Agree how per-user and per-GB charges appear on the invoice.

Common mistakes

One global admin account used for every client. If it is phished, every client is exposed at once. Why it happens: it is the fastest way to start. Instead: use delegated, least-privilege roles per client and review them each quarter.
Treating retention as backup. Vault keeps nothing until a rule exists, and keeping data for search is not the same as restoring it. Why it happens: both promise that deleted data is “still there”. Instead: decide on a backup tool per client and write down what it covers.
Bundling a per-GB cost into a flat per-user fee with no cap. In the example, backup rises from 15.6% to 22.3% of the fee in a year. Why it happens: one flat price is easier to sell. Instead: pass storage costs through or set an included allowance.
Never testing a restore. The first restore is the one the client is watching. Why it happens: backups report success every night, so nobody checks. Instead: restore a mailbox and a site for each client once a quarter and keep the log.

Sources

Microsoft Learn, GDAP introduction, checked October 17, 2026.
Microsoft Learn, Overview of Microsoft 365 Lighthouse, checked October 17, 2026.
Microsoft Learn, Overview of Microsoft 365 Backup, checked October 17, 2026.
Google Workspace Admin Help, Vault overview, checked October 17, 2026.

In three sentences

An MSP running client SaaS needs separate, least-privilege admin access per client, one console to watch many tenants, and a backup decision made before anything is lost. Microsoft offers GDAP for access, Lighthouse as a no-cost console and Microsoft 365 Backup at $0.15 per GB a month, while Google Vault keeps nothing until retention rules exist. In the example, backup inside a flat $60 fee grows from 15.6% to 22.3% of it in a year, so pass per-GB costs through and test restores quarterly.

SaaS SLAs: uptime, support and service credits explained

Ricardo Machado — Mon, 26 Oct 2026 16:00:00 GMT

A vendor promises “99.9% uptime”, your team depends on the product every day, and you need to know what that promise is worth when the service goes down. The answer is in the service level agreement (SLA): the part of the contract that sets a measurable commitment, such as uptime, and what the vendor owes you when it misses it.

Most SaaS SLAs promise less than the headline suggests, and pay less than an outage costs you. This guide turns uptime percentages into minutes, takes an SLA apart clause by clause, compares two published SLAs and works a service credit through. For the basics of software delivered as a service, see What is SaaS?.

An SLA in plain terms

Think of a pizza shop that promises delivery within 30 minutes or your next pizza is free. If the pizza is late, you do not get your party back. You get a voucher, and only if you ask for it, and not if the delay was caused by a snowstorm.

An SLA works the same way. The vendor commits to a number. If it misses, you can claim a service credit: extra days of service or a discount on a future bill. The credit is a small refund, not compensation for what the outage cost your business.

The parts of an SLA

Read every SLA for these seven parts:

The commitment. Usually a monthly uptime percentage, such as 99.9%.
The measurement window. Most measure per calendar month, so a bad day is averaged over the month.
The definition of downtime. This decides what counts. A total outage counts everywhere; a slow or partly broken service may not.
Exclusions. Scheduled maintenance, force majeure, your own network and third-party products are commonly excluded.
Service credits. A table that maps uptime ranges to a credit.
The claim process. Who must ask, how and by when. Credits are rarely automatic.
Caps and sole remedy. A maximum credit, and often a clause that the credit is your only remedy for the outage.

Support response times are a separate commitment, sometimes in the SLA and sometimes in a support policy. Check whether they promise a first response or a fix, and for which severity levels.

What uptime means in minutes

A 30-day month has 30 x 24 x 60 = 43,200 minutes. A 365-day year has 525,600. The allowed downtime is the share of those minutes not covered by the commitment.

Uptime commitment	Allowed downtime per 30-day month	Allowed downtime per year
99%	43,200 x 1% = 432 minutes (7.2 hours)	5,256 minutes (87.6 hours)
99.5%	216 minutes (3.6 hours)	2,628 minutes (43.8 hours)
99.9%	43.2 minutes	525.6 minutes (8.76 hours)
99.95%	21.6 minutes	262.8 minutes (4.38 hours)
99.99%	4.32 minutes	52.56 minutes

Each extra nine cuts allowed downtime by a factor of ten. Moving from 99.9% to 99.99% takes the monthly allowance from 43.2 minutes to under 5.

Two published SLAs compared

Two vendors publish their SLA terms in full. Their numbers are close; their mechanics differ.

Clause	Google Workspace	Atlassian cloud
Commitment	99.9% monthly uptime	99.9% on Premium, 99.95% on Enterprise
Downtime means	More than a 5% user error rate	A minute with an error rate above 5%
Credit, below 99.9% down to 99.0%	3 days of service added	10% (Premium and Enterprise)
Credit, below 99.0% down to 95.0%	7 days	25%
Credit, below 95.0%	15 days	50%
Extra tier	None	Enterprise: 5% below 99.95% down to 99.9%
Claim deadline	Support case within 30 days of becoming eligible	Ticket within 15 days after the end of the month
Cap	15 days of service per month	Read the full terms
Page date	Last modified August 31, 2026	Effective April 30, 2026

Sources: Google Workspace SLA and Atlassian cloud SLA, both checked October 17, 2026. Atlassian excludes routine scheduled maintenance and reasonable emergency maintenance under its maintenance policy.

Not every vendor publishes a number. Slack’s public service level page (effective July 11, 2024) promises “commercially reasonable efforts” to keep the service available around the clock, with no percentage. Paid enterprise contracts may say more. The point stands: the SLA that binds you is the one in the contract you sign.

A credit, worked through

Example: a hypothetical team pays $12,000 a month for a SaaS product. In a 30-day month, the service is down for 2 hours.

Downtime: 2 x 60 = 120 minutes.
Share of the month: 120 / 43,200 = 0.28%.
Uptime: 100% - 0.28% = 99.72%, below 99.9% and above 99.0%.
Under tiers like Atlassian’s Premium table, assuming the credit applies to the full monthly fee: $12,000 x 10% = $1,200.
Under tiers like Google’s: 3 days of service. At $12,000 / 30 = $400 a day, that is worth 3 x $400 = $1,200.

Now the cost of the same outage to the business. If 200 staff lose 2 hours each at a loaded cost of $50 an hour: 200 x 2 x $50 = $20,000. The credit covers $1,200 / $20,000 = 6% of it. Plan for outages with your own workarounds; the credit will not fund them.

Checklist

Before you sign, tick each line:

The uptime percentage, measurement window and downtime definition are written down, not only on a marketing page.
Partial outages that block your main use case count as downtime.
Scheduled maintenance has a notice period and a cap on hours.
You know the claim deadline, and someone owns the claim.
Support terms state response times per severity level.
You run your own monitoring, so you can prove the outage minutes.
Your plan for a long outage does not depend on the credit.

For monitoring, the vendor’s status page is a start, but it reports what the vendor sees. A simple external check that signs in and loads a page every few minutes gives you your own record. Put SLA review into vendor selection, see how to evaluate SaaS solutions, and into the contract stage of enterprise SaaS deals.

Common mistakes

Reading 99.9% as “almost never down”. It allows 43.2 minutes a month, more than 8.7 hours a year. Why it happens: the percentage looks close to 100. Instead: convert every commitment to minutes before comparing vendors.
Missing the claim deadline. Credits are rarely automatic: 30 days at Google, 15 days after month end at Atlassian. Why it happens: nobody owns the claim during the incident. Instead: assign an owner and log outage times as they happen.
Treating the credit as insurance. A $1,200 credit against a $20,000 loss covers 6%. Why it happens: the SLA reads like a guarantee. Instead: plan workarounds and, for critical systems, negotiate higher credits or termination rights for repeated misses.
Ignoring the downtime definition. A slow or partly broken service may not count. Why it happens: the definition sits deep in the document. Instead: read it first, and ask how the vendor measures error rates.

Sources

Google, Google Workspace Service Level Agreement, last modified August 31, 2026, checked October 17, 2026.
Atlassian, Cloud service level agreement, effective April 30, 2026, checked October 17, 2026.
Slack, Service level agreement, effective July 11, 2024, checked October 17, 2026.

In three sentences

A SaaS SLA sets a measurable commitment, usually monthly uptime, and the service credit you can claim when the vendor misses it. A 99.9% commitment still allows 43.2 minutes of downtime a month, and the downtime definition, exclusions and claim deadline decide what you can actually recover. Credits are small next to the cost of an outage, such as $1,200 against $20,000 in the example, so convert every promise to minutes, monitor it yourself and plan your own workarounds.

SaaS implementation: a step-by-step rollout plan for business teams

Ricardo Machado — Fri, 23 Oct 2026 11:00:00 GMT

Your company has signed for a new SaaS product, the contract start date is fixed, and you have been told to “get everyone on it”. You need a plan that turns a login page into a tool people use, without losing data on the way. A SaaS implementation is that plan: six phases, from writing down what the tool must do to measuring whether people use it.

The vendor runs the servers, so implementation is not about installing software. It is about configuration, data, connections and people. Those four are yours, whatever the contract says. If the split between what the vendor runs and what you run is new to you, start with What is SaaS? and SaaS in cloud computing.

Implementation in plain terms

Think of it like moving into a furnished apartment. The landlord owns the building, the plumbing and the furniture. You still have to decide which room is for what, carry your boxes in, label them, get the internet connected and show your family where things are. An apartment full of unopened boxes is not a home, however good the building.

In SaaS terms, the building is the vendor’s product. Your boxes are your data. The internet connection is your integrations. Showing the family around is training. Implementation ends when people live in the new place, not when the keys change hands.

The six phases

Each phase ends with a written output. If a phase has no output, it did not happen.

Requirements. List the processes the tool must support, in the order people do them today. Mark each as required, useful or later. Output: a requirements list signed by the business owner.
Configuration. Set up the product to match those processes: fields, workflows, roles, permissions and naming. Change your process before you customize the product, where the product’s default is reasonable. Output: a configuration record, so the next admin knows what was changed and why.
Data migration. Export from the old system, clean, map each field to the new one, test-import a sample, fix, then import everything. Output: a reconciliation report (records exported against records imported).
Integrations. Connect identity first: single sign-on (SSO), so people log in with their company account, and user provisioning. SCIM (System for Cross-domain Identity Management), an IETF protocol published as RFC 7644 in September 2015, lets your identity provider create and remove accounts automatically. Then connect the tools that feed or read the new system. Output: an integration list with owners.
Training. Train by role, on the tasks each role does every week, with the company’s real data. Output: a short guide per role and a list of who attended.
Adoption. Measure use after go-live and act on it. Output: a 30-day and a 90-day adoption report.

Who does what: a RACI table

A RACI table assigns one role per task: Responsible (does the work), Accountable (owns the result, one person only), Consulted (asked before) and Informed (told after). The table below is a starting point for a mid-size rollout. Adjust the roles to your company.

Task	Business owner	Project lead	IT / admin	Vendor
Requirements list	A	R	C	C
Configuration	C	A	R	C
Data migration	I	A	R	C
SSO and provisioning	I	C	A, R	C
Training	C	A	I	R
Adoption report	A	R	C	I

Two rules make the table useful. Only one person is accountable for each row. And the vendor is never accountable: the contract makes the vendor responsible for its service, not for your rollout.

Worked example: migration effort and unused seats

Example: a labeled hypothetical. A company moves 48,000 customer records into a new CRM and buys 120 seats at $30 per seat per month.

Migration. A test import of the full file rejects 4% of records (missing required fields, bad dates, duplicates).

Records to fix: 48,000 x 4% = 1,920.
At 2 minutes per record: 1,920 x 2 = 3,840 minutes.
In hours: 3,840 / 60 = 64 hours, or eight working days of 8 hours for one person.

That is eight days nobody put in the plan. A sample import of 500 records in phase 3 would have shown the 4% rate before the go-live date was set.

Adoption. Thirty days after go-live, 78 of the 120 licensed users were active in a given week.

Measure	Calculation	Result
Weekly active rate	78 / 120	65%
Inactive seats	120 - 78	42
Monthly cost of inactive seats	42 x $30	$1,260
Yearly cost of inactive seats	$1,260 x 12	$15,120

The $15,120 is the cost of a rollout that stopped at go-live. Follow up with each inactive user’s manager before the renewal date, and reduce the seat count if the contract allows it. For how per-seat contracts are priced, see SaaS pricing models.

Go-live checklist

The requirements list is signed and every required item is configured and tested.
A full test import ran, and the reconciliation report shows exported and imported counts that match, or explains each difference.
The old system is set to read-only from the cutover date, so nobody writes to two places.
SSO works for every user group, and leaving staff lose access through provisioning, not by hand.
Every integration on the list has been tested with real records and has a named owner.
Each role has a one-page guide and a named person to ask in the first two weeks.
Admin rights are limited to the people who need them, and at least two people hold them.
An export of the new system’s data has been run and opened, so you know your exit works.
The 30-day adoption measure and its target are written down before go-live.

Common mistakes

Recreating the old system inside the new one. Every old custom field and workaround is copied across, and the new tool becomes as hard to use as the old one. Why it happens: it feels safer to change nothing. Instead: start from the product’s defaults and add a custom field only when a requirement needs it.
Migrating data without a sample test. The first full import fails on the night before go-live. Why it happens: migration is planned as one step. Instead: import a sample early, measure the rejection rate and budget the fixing time, as in the example.
Training on features instead of tasks. People sit through a tour of every screen and remember none of it. Why it happens: the vendor’s standard training is feature-based. Instead: train each role on the five tasks it does every week, with its own data.
Declaring success at go-live. Logins on day one say nothing about week six. Why it happens: the project team moves on. Instead: keep the adoption report in the plan, with a named owner, until the 90-day mark.

For a worked case of a per-seat tool that grows with the team, see CRM SaaS.

Sources

IETF, RFC 7644: System for Cross-domain Identity Management: Protocol, September 2015.

In three sentences

A SaaS implementation has six phases, requirements, configuration, data migration, integrations, training and adoption, and each one ends with a written output. In the example, a 4% rejection rate on 48,000 records means 64 hours of fixing, and 42 inactive seats at $30 cost $15,120 a year. Test a data sample early, give each task one accountable owner and keep measuring use after go-live, because the rollout is finished only when people work in the new tool.

SaaS integration: APIs, webhooks, iPaaS and the patterns that hold up

Ricardo Machado — Wed, 21 Oct 2026 11:00:00 GMT

You run a CRM, a billing tool and a help desk, and the same customer has a different email address in each one. A paid invoice never reaches the sales record, and support cannot see who is on which plan. You need the tools to share data, and you need to pick how before someone builds a fragile script at midnight.

A SaaS integration is any connection that moves data or triggers actions between two hosted applications. Because you do not control either vendor’s servers, every integration goes through what the vendors expose: APIs, webhooks and connector platforms. If SaaS itself is new to you, start with What is SaaS?.

Integration in plain terms

Think of a restaurant. An API is the counter: you walk up, ask for something and get an answer. A webhook is the buzzer they hand you: you do not keep asking whether your food is ready, the buzzer tells you. An iPaaS (integration platform as a service) is a delivery service that carries orders between many restaurants for you, for a fee per trip.

Each one solves a different problem:

API (application programming interface): a documented way for your code to ask another application for data or to change it.
Webhook: an HTTP message an application sends to a URL you choose when something happens, such as “invoice paid”.
iPaaS: a hosted service with ready-made connectors where you define “when this happens in app A, do that in app B” without running your own servers.
Batch sync: a scheduled job that copies records in bulk, often nightly.

Four patterns compared

Pattern	How data moves	Good for	Watch out for
Direct API calls	Your code asks app B for data or writes to it	Full control, complex logic	Rate limits, authentication, code you maintain
Webhooks	App A pushes an event to your endpoint	Reacting fast to changes	Duplicates, events out of order, endpoint downtime
iPaaS connectors	A hosted platform runs “if this, then that” flows	Small volumes, no developers	Per-task pricing, limited error handling
Batch sync	Bulk copy on a schedule	Reporting, data warehouses	Stale data between runs, long run times

Many setups end up with a mix. A webhook tells you a payment happened, an API call fetches the details, and a nightly batch feeds reporting. The table is a starting point for choosing per flow, not per company.

API rate limits: the arithmetic you need first

Every SaaS API limits how many requests you can send. The limits are public, and they decide whether a sync finishes overnight or runs into the next morning. HubSpot publishes its limits for privately distributed apps by subscription tier (HubSpot usage guidelines, as of October 2026):

Free and Starter: 100 requests per 10 seconds per app, 250,000 per day per account.
Professional: 190 per 10 seconds, 625,000 per day.
Enterprise: 190 per 10 seconds, 1,000,000 per day.

The 10-second limit applies to each app. The daily limit is shared by every app in the account.

Example: you plan a nightly job that updates 250,000 contact records, one API request per record.

On a Starter account: 100 requests per 10 seconds = 10 per second. 250,000 / 10 = 25,000 seconds, or 25,000 / 3,600 = 6.9 hours.
The job also uses 250,000 of the 250,000 daily requests. Every other app on that account then hits the shared daily limit.
On Professional: 190 per 10 seconds = 19 per second. 250,000 / 19 = 13,158 seconds, or 3.7 hours, and 250,000 / 625,000 = 40% of the daily allowance.

A bigger plan is not the only fix. Send only the records that changed since the last run, and use the vendor’s batch endpoints where they exist. If 5% of contacts change on a given day, the same job needs 250,000 x 5% = 12,500 requests, which takes 12,500 / 10 = 1,250 seconds, about 21 minutes, on Starter.

Webhooks: fast, but plan for repeats

Webhooks spare you from asking “anything new?” every minute. They also come with delivery rules you have to handle. Stripe’s documentation is explicit about three of them (Stripe webhooks, as of October 2026):

Retries. If your endpoint does not answer with a success code, Stripe retries delivery for up to three days in live mode, with exponential backoff.
Duplicates. The same event can arrive more than once. Stripe advises logging the event IDs you have processed and skipping repeats.
Order. Stripe does not guarantee events arrive in the order they were created. An “invoice paid” event can arrive before “subscription created”.

Stripe also advises returning a success response quickly, before running slow logic, and processing events from a queue. That pattern applies to webhooks from any vendor: accept, store, answer, then process.

iPaaS: priced by the task

Connector platforms charge for the work they do. Zapier, for example, counts a task “whenever Zapier successfully completes a unit of work for you”. Triggers and failed actions do not count. Billed annually, its Professional plan costs $19.99 a month for 750 tasks or $39.00 for 1,500 tasks. The Team plan starts at 2,000 tasks for $69.00 a month (Zapier pricing, as of October 2026).

Example: each new order runs one flow with three actions: create the invoice line, update the CRM deal and post a message to the sales channel.

Orders per day	Tasks per month (orders x 3 x 30)	Smallest listed tier that covers it (billed annually)
5	5 x 3 x 30 = 450	Professional, 750 tasks, $19.99
15	15 x 3 x 30 = 1,350	Professional, 1,500 tasks, $39.00
40	40 x 3 x 30 = 3,600	Above Team’s 2,000 tasks; check the price of a larger tier

The table shows where iPaaS fits. At low volume it costs less than a developer’s time. As volume grows, the task bill climbs with every order, while a direct API integration costs roughly the same at 40 orders a day as at 5.

How to choose, flow by flow

Who owns the data? Pick one system as the source of truth for each field, such as billing for plan and price, CRM for owner and stage. Integrations copy from the owner, never both ways on the same field.
How fresh must it be? Seconds means webhooks. Hours means a scheduled sync. Next day means a batch.
How much volume? Multiply records by changes per day and compare with the API limits and task prices above.
Who fixes it at 2 a.m.? An iPaaS flow a manager built has no on-call engineer. Decide who receives the error emails.

For how vendors open their products to integrations through APIs and app marketplaces, see What is a SaaS platform?. For a CRM-side view of the same problem, see CRM SaaS. For who runs what in a hosted application, see SaaS in cloud computing.

Common mistakes

Syncing both ways on the same field. Two systems overwrite each other in a loop, and the last writer wins at random. Why it happens: each team wants to edit data in its own tool. Instead: name one owner per field and sync one way.
Ignoring rate limits until the first full sync. The test with 100 records works; the real run with 250,000 takes hours and uses up the daily allowance. Why it happens: limits sit in a separate documentation page. Instead: do the arithmetic in the example above before you build.
Processing a webhook twice. A retried “invoice paid” event creates two receipts or two credits. Why it happens: the handler assumes one delivery per event. Instead: store each event ID and skip any you have already processed.
Letting an iPaaS flow fail silently. A changed field name breaks a flow, and nobody notices for weeks. Why it happens: error alerts go to the person who built it, who may have left. Instead: send failures to a shared channel and review the run history monthly.

Sources

HubSpot, Usage guidelines, checked October 2026.
Stripe, Receive Stripe events in your webhook endpoint, checked October 2026.
Zapier, Pricing, checked October 2026.

In three sentences

SaaS integration connects hosted applications through APIs, webhooks, iPaaS connectors or batch syncs, and you will usually need a mix chosen flow by flow. At HubSpot’s Starter limit of 10 requests a second, a full sync of 250,000 records takes 6.9 hours and uses the daily allowance, while syncing only the 5% that changed takes about 21 minutes. Name one owner per field, do the rate-limit and task arithmetic before building, and design every webhook handler for retries, duplicates and events out of order.