Building an integration for a single company is relatively straightforward. You configure static credentials, point your code at one Salesforce org and one QuickBooks Online company, and write the synchronization scripts. It runs, it syncs, and you move on.
A multi-tenant SaaS application is a different engineering problem entirely. Every customer who signs up brings their own Salesforce instance and their own QuickBooks Online company, and each of those connections has its own credentials, its own schema quirks, and its own failure modes. That single structural fact ripples through your whole codebase. You now have to handle tenant-specific credentials, OAuth consent flows, encrypted token storage, and customer-to-account mapping, and on top of that you inherit divergent Salesforce schemas, varying QuickBooks configurations, synchronization state tracking, asynchronous webhook processing, background retries, rate limits, and disconnections that require reauthorization.
Both platforms also moved under your feet in 2025 and 2026, which is the first thing an experienced architect checks before writing any code. Salesforce authorization now runs on OAuth 2.0 through External Client Apps, the construct that is replacing classic Connected Apps as the recommended path for new integrations as of the Spring ’26 release. QuickBooks Online requires OAuth 2.0 for customer authorization and token exchange, and in July 2025 Intuit launched its App Partner Program, which meters read traffic and introduces platform fees that change how you should design the integration, not just how you bill for it. Without a deliberate architectural boundary, these third-party dependencies tangle straight into your core product logic, and that is the mistake this guide is built to prevent.
The Architecture I Would Use for a SaaS Integration
Weaving direct third-party API calls into your primary application controllers produces a fragile codebase. When an upstream API version retires or a token expires, your core product should not so much as flinch, let alone crash.
A reliable multi-tenant integration runs behind a decoupled service layer, so the data path is always your SaaS application to an integration service to Salesforce or QuickBooks Online, never your application calling those APIs directly. Inside that integration service, I separate responsibilities into distinct modules that each do one job. There are API clients that own direct upstream communication, an authentication and token management service, tenant configuration storage, and a mapping layer for data transformation. A synchronization engine coordinates the actual work, webhook handlers receive inbound events, and a queue with background workers absorbs the load. Around all of that sit a retry mechanism with backoff, a dedicated integration database, and logging and monitoring so you can see what is happening. Keeping these concerns modular is not architectural decoration. It is what lets you swap an API client or add a second accounting system later without touching the rest.
Isolating integration concerns behind this layer protects your core business logic from events you do not control. When an upstream rate limit trips, a token gets revoked, or you decide next year to support a different CRM, the blast radius stays inside the integration service and your primary application remains stable.
Decide What System Owns Each Piece of Data
Writing sync code before you establish data ownership is how you end up with race conditions and duplicate records. You have to define a system of record for each object before a single field moves.
In most SaaS billing integrations, the ownership lines fall in a familiar pattern. Salesforce owns the sales side: leads, opportunities as the pipeline system of record, and sales activity metrics. QuickBooks owns the money side: invoices, payment statuses, and accounting transactions. The gray areas are customers, accounts, products, and services, which depend on your specific business model and catalog implementation rather than on any universal rule. A usage-based product, for instance, often generates invoices internally first and then pushes them to QuickBooks, which inverts the default assumption that accounting owns invoicing.
The principle underneath all of this is that an integration synchronizes business ownership; it does not blindly mirror database tables between two foreign APIs. Salesforce’s own guidance frames the goal as coordinating customer information, sales orders, expenses, and invoicing between the CRM and accounting layers, and that framing is the right mental model. Decide who owns each object, write it down, and let that document govern every sync decision that follows.
Map the Business Workflow Before Mapping API Fields
The common failure is jumping straight to field-level mappings, staring at Salesforce objects and QuickBooks entities before understanding the sequence of human and automated events that connects them. Field mapping without workflow mapping produces an integration that technically moves data and still gets the business wrong.
Start with the lifecycle of a transaction. When a Salesforce opportunity reaches closed-won, your integration service receives an event. It identifies the correct tenant, matches the customer account, prepares the billing payload, creates the invoice in QuickBooks, captures the assigned QuickBooks ID, and updates the SaaS application state. That is the forward path, and every step in it is a place something can go wrong, which is exactly why you map it first.
The reverse path handles the accounting side. When a QuickBooks invoice changes status, a webhook arrives at your endpoint. The service validates the event signature, retrieves the updated record if it needs the full details, updates the internal SaaS record, and pushes the accounting status back to Salesforce if the CRM needs visibility into it. Defining both flows on paper gives you a working mental model of the system before you write a line of integration code, and it surfaces the ownership and idempotency questions early, while they are still cheap to answer.
Salesforce APIs: Choose the API for the Job
Salesforce is not one API; it is a portfolio, and reaching for the standard REST API for every task is how you create performance bottlenecks. The current version as of the Summer ’26 release is v67.0, and Salesforce ships three releases a year, so pin your integration to a current, supported version and track the retirement schedule deliberately. Versions 21.0 through 30.0 were retired in Summer ’25 and now return HTTP 410, and Salesforce has already announced that versions 31.0 through 40.0 will be deprecated in Summer ’27 and retired in Summer ’28. Building on a version that is about to disappear is a self-inflicted outage.
Match the API to the workload. Use the REST API for ordinary record-level operations and straightforward transactional requests. Reach for Composite resources when a workflow needs several Salesforce operations in one round trip, which cuts latency and keeps related writes together. For large-volume synchronization rather than individual records, use Bulk API 2.0, which Salesforce designates specifically for large data loads and asynchronous batch processing. For event-driven work where your application needs to react to Salesforce changes without polling, use the Pub/Sub API, now the recommended path for new event-driven integrations, together with Platform Events for real-time exchange with external systems. In a typical SaaS integration, those three surfaces divide the labor cleanly: REST handles transactional record operations, Bulk API 2.0 runs the large background jobs, and Pub/Sub with Platform Events eliminates the polling that would otherwise burn your API allocation.
One 2025 change is worth noting here because it affects async design. Salesforce Functions was retired in 2025, so if you were planning to lean on it for asynchronous processing, the modern answer is Platform Events, Pub/Sub, external serverless, or Apex async patterns instead.
QuickBooks Online APIs: What the SaaS Application Actually Needs
QuickBooks Online exposes a v3 Accounting API built on REST and JSON, with every call following the pattern of a company base URL keyed by realm ID, at quickbooks.api.intuit.com for production and a matching sandbox host. Intuit does not use traditional API keys; you register an app on the Intuit Developer Portal to obtain OAuth 2.0 client credentials and authorize per company from there. Official SDKs exist for Node.js, Python, Java, .NET, PHP, and Ruby, so you rarely need to hand-roll the HTTP layer.
Your integration will touch a focused subset of the data model. Customer records hold billing profiles, Invoice entities carry billing transactions, and Payment records track cash flow. Item entries define line-item products and services, Sales Receipts cover point-of-sale style transactions, Credit Memos handle refunds and adjustments, and tax entities cover regional compliance. Two behaviors of this API shape your code more than the entity list does. Updates are full-object replacements guarded by a SyncToken for optimistic locking, so you send the complete entity and the current token or the write is rejected, and hard deletes are available only on transaction entities while name-list entities such as customers and items are deactivated by setting Active to false rather than removed.
The platform limits are strict and specific. QuickBooks throttles standard endpoints at 500 requests per minute per realm ID with a maximum of 10 concurrent requests, throttles the batch endpoint separately at a much lower rate on the order of tens of requests per minute per realm with up to 30 entities per batch request, and caps resource-intensive report endpoints around 200 requests per minute. Exceeding any of these returns an HTTP 429 with the ThrottleExceeded error code; responses over 1,000 entities must be paginated, and report responses are capped at 400,000 cells. Design around these numbers from the start rather than discovering them in production.
OAuth Is a Product Feature, Not Just an API Setup Step
In a SaaS application, OAuth is part of the onboarding experience, not a one-time script an administrator runs. The moment a customer clicks a Connect Salesforce or Connect QuickBooks button in your settings panel, you are in the middle of your product’s user experience, and it needs to feel like it.
The flow begins with that button, which opens the provider’s consent dialog and returns an authorization code your application exchanges for access and refresh tokens. QuickBooks requires OAuth 2.0 authorization for any access to company data, and its token behavior is precise: access tokens expire after 60 minutes, and refresh tokens rotate on a schedule. Following a change Intuit announced in November 2025, those refresh tokens now carry a much longer maximum validity – up to several years, rather than the old 100-day ceiling – but they still rotate, so your token service must always persist the newest refresh token it receives, or it will lock a customer out. On the Salesforce side, use an External Client App rather than a classic Connected App for anything new. External Client Apps are closed by default, meaning each org must explicitly install and authorize them; they separate developer settings from admin policy, and they support the full range of OAuth flows a multi-tenant integration needs.
The SaaS-specific security requirements are non-negotiable. Never store credentials in application code, encrypt all tokens at rest, and isolate tenant credentials so no query can ever return one customer’s tokens to another. Request the minimum OAuth scopes your features actually require, refresh tokens automatically before they expire, detect revoked authorizations gracefully instead of failing loudly in a customer’s face, and give every customer a self-service way to disconnect and reconnect. Treating disconnection as a first-class product state, not an error, is what separates an integration that ages well from one that generates support tickets.
Design the Tenant Model Before Writing Synchronization Code
A multi-tenant integration needs a data layer that isolates each customer’s external connections completely, and getting that schema right before you write sync logic saves you from a painful migration later.
Your model has to represent the real relationships without mixing identifiers across accounts. Each SaaS tenant maps to a Salesforce organization through an active Salesforce connection, and separately to a QuickBooks realm through an active QuickBooks connection. The connections are their own records because they come and go: a customer disconnects, reauthorizes, or moves from a sandbox to production, and the tenant survives all of it. External identifiers must live separately from your internal system IDs, because hardcoding a Salesforce or QuickBooks foreign key into your core tables creates architectural debt the first time a customer reconnects a different account.
The workhorse here is an explicit mapping table that ties an internal customer identifier to its Salesforce organization and record identifiers and to its QuickBooks realm and entity identifiers. That indirection is what lets a customer revoke access and reconnect their accounting software while your application simply updates the mapping reference, leaving historical order records and internal analytics untouched. Build this layer as if reconnection is inevitable, because at scale it is.
Build a Canonical Data Model Instead of Translating Directly Between APIs
Mapping Salesforce fields straight to QuickBooks fields feels efficient until the integration grows, at which point every new system you connect forces you to rewrite every mapping function from scratch. That is a trap you can design your way out of on day one.
Introduce an intermediate translation layer so data flows from a Salesforce object into a canonical SaaS model and only then into a QuickBooks entity. A Salesforce Account becomes a canonical Customer before it generates a QuickBooks Customer, and a Salesforce Opportunity becomes a canonical Billing Event before it creates a QuickBooks Invoice. The external systems now touch your canonical model rather than each other.
That indirection buys you control that direct mapping never can. Your canonical model is the single place you enforce normalization, field validation, business rules, source tracking, and conflict resolution, and because the external APIs evolve independently of it, a breaking change on either side is contained to one adapter instead of rippling through your business logic. When Salesforce ships v68.0, or Intuit revises an entity, you update one translation boundary, not the whole system.
Decide Whether Synchronization Should Be One-Way or Bidirectional
The direction of data flow is the single biggest lever on your system’s complexity, and unidirectional synchronization is dramatically easier to build, test, and operate than a bidirectional model. Choose deliberately rather than defaulting to two-way because it sounds more complete.
Salesforce-to-QuickBooks sync fits when sales activity drives billing, which covers most SaaS businesses. QuickBooks-to-Salesforce sync becomes necessary when accounting statuses need to be visible inside the CRM, for example, so an account executive can see that an invoice was paid. Bidirectional sync is genuinely powerful, but it introduces a specific and severe hazard: naive two-way syncing creates infinite update loops. A record changes in Salesforce, which updates QuickBooks, which fires a webhook, which updates Salesforce, which fires another event, and around it goes. Preventing that requires strict change-origin tracking, event identifier logging, idempotency keys, and last-synchronized timestamp comparisons, all of which you have to build before you turn bidirectional sync on, not after it melts down.
Use Events and Webhooks Instead of Polling Everything
Constant polling to detect changes wastes your API allocation and adds latency, and with Intuit now metering QuickBooks read traffic, it also wastes money. Event-driven design is the default for a reason.
QuickBooks provides webhooks for real-time change notifications once a company completes OAuth, and Salesforce provides Platform Events and the Pub/Sub API for instant event streaming. There is an important QuickBooks-specific wrinkle: its webhooks send a reference payload only, containing the entity name, ID, and operation type, so you always make a follow-up API call to fetch the full record. Under the App Partner Program, that follow-up read counts against both your rate limit and your metered read quota, which means your webhook handler should fetch once, cache what it can, and avoid re-reading data it already has.
Polling still earns its place, just not for everything. Use it for the initial customer data load, periodic reconciliation, disaster recovery after extended downtime, and scheduled consistency checks. The robust production pattern combines the two: webhooks for timely change detection, and controlled polling for initial loads and recovery routines.
Put Synchronization Behind a Queue
Synchronous API calls will wreck your application’s performance the moment an external service slows down or fails. A customer-facing request must never wait while your server runs a chain of upstream Salesforce and QuickBooks calls, because that couples your response times to systems you do not control.
Route every synchronization task through an asynchronous pipeline, so an inbound webhook or API event is validated, placed on a queue, picked up by a worker, transformed through your canonical model, sent to the external API, and its result recorded in sync state. That structure is what makes automatic retries, exponential backoff, rate-limit management, workload isolation, dead-letter queues for poison jobs, and real observability possible at all. It also insulates your core SaaS application from a temporary outage in either third-party ecosystem, which turns an upstream incident into a delayed sync rather than a customer-visible failure.
API Limits Change the Way the Integration Should Be Built
The QuickBooks limits are not footnotes; they are design constraints. Standard endpoints allow 500 requests per minute per realm ID with a maximum of 10 concurrent requests; the batch endpoint is throttled separately at a much lower rate with up to 30 entities per batch, and report endpoints sit around 200 requests per minute, all returning HTTP 429 when exceeded, with pagination required beyond 1,000 entities. Since July 2025, there is a cost dimension on top of the rate dimension: under Intuit’s App Partner Program, writes remain free while reads are metered and priced in tiers, so an inefficient read pattern now shows up on an invoice, not just in a latency graph.
These constraints dictate your code structure. Avoid unnecessary API calls, cache reusable reference data such as tax rates and item lists locally, batch mutations where the API supports it, paginate large datasets properly, and implement exponential backoff with jitter when you hit a limit. The multi-tenant twist is that the 500-per-minute ceiling is per realm ID, not per your application, so a single enterprise customer with tens of thousands of invoices can exhaust its own limit during one paginated sync. That is why you monitor and throttle load per tenant rather than tracking only total application traffic. One high-volume customer must never consume the capacity or the read budget that the rest of your platform depends on.
Idempotency Is What Prevents Duplicate Customers and Invoices
Network timeouts are inevitable in distributed systems, and they create a genuinely ambiguous situation: when a request to create a QuickBooks invoice times out, your worker cannot know whether the server processed it before the connection dropped. That ambiguity is where duplicate financial records come from.
If the worker retries blindly, you create a second invoice and bill the customer twice, which is the kind of bug that costs trust rather than just time. The defense is idempotency by design. Use external transaction IDs, write your synchronization state before you dispatch the network call rather than after, apply deterministic matching rules, and perform a pre-creation lookup to check whether the record already exists before you create it. QuickBooks helps here in specific cases, but the discipline is yours to enforce: every retry attempt must be classified so it can execute safely, and no code path should ever create a financial record without first establishing that an equivalent one does not already exist.
Error Handling Needs to Distinguish Failure Types
Generic try-catch handling fails in a real integration because different failures demand different automated responses, and treating them all the same guarantees the wrong one somewhere.
Categorize the exceptions and route each to its correct response. Authentication failures, where a token has expired or been revoked, call for an automatic token refresh or, if that fails, a clear prompt to the user to reconnect. Validation failures from bad field mappings or missing required data need to stop and wait for administrative review rather than retry, because retrying invalid data just fails faster. Rate-limit failures should pause and back off. Network timeouts are safe to retry only when the operation is idempotent, which is exactly why the previous section matters. Business conflicts, where the underlying states genuinely disagree, should block further processing until resolved rather than paper over the disagreement. Permanent failures belong in a failed-review state immediately, not in an endless retry loop that quietly burns your API budget. Underpinning all of this, every job must track its lifecycle explicitly across pending, processing, retry-scheduled, and failed states, because you cannot operate what you cannot see.
Reconciliation Is How You Know the Integration Is Actually Working
Webhooks and event listeners fail silently. Packets drop, payloads corrupt, an endpoint is briefly down, and the event you were counting on simply never arrives with no error to tell you so. A production-grade integration treats reconciliation as a required second line of defense, not an optional extra.
Schedule background jobs that periodically compare Salesforce customer mappings against QuickBooks records, identify entities missing on either side, cross-reference invoice IDs and payment statuses, detect synchronization jobs that have stalled, and reprocess the discrepancies that are safely recoverable. Reconciliation is what lets the system self-heal over time, closing the small gaps that event-driven delivery inevitably leaves, so that the answer to whether the integration is actually in sync comes from a scheduled check rather than from a customer noticing a missing invoice.
Security Should Follow the Data, Not Just the APIs
Connecting a customer’s accounting system to their CRM means moving financial and customer data across trust boundaries, and perimeter defenses alone do not cover that. The controls have to follow the data itself.
Enforce least-privilege OAuth scopes so your application requests only the permissions its features actually use, and encrypt all access and refresh tokens at rest with a managed key service rather than a hardcoded secret. Isolate tenant data at the query level, so isolation is a property of your data access layer and not a convention developers have to remember. Require strict TLS on every hop, and keep comprehensive audit logs for every authorization change, token refresh, and access to sensitive financial data, because when a customer or an auditor asks who touched what and when, a complete log is the only acceptable answer. Given that AI app builders and integration platforms both suffered credential and data-exposure incidents through 2025, an independent security review of this layer before launch is worth far more than it costs.
Direct API Integration or Middleware?
Deciding between building direct API integrations and adopting third-party middleware is a genuine architectural fork, and the right answer depends on what the integration means to your business.
Direct integration wins when the integration is a core product differentiator, when you need deep workflow customization, and when you have the engineering resources to own it. Middleware wins when you need to connect dozens of standard tools quickly and would rather offload connector maintenance than build it. Salesforce positions MuleSoft as its recommended enterprise integration platform and offers native connectors, and Salesforce’s broader 2026 direction leans further into managed and AI-agent-driven integration, including hosted MCP Servers that reached general availability in the Summer ’26 release. That direction is worth watching. But a SaaS product that sells its Salesforce and QuickBooks integration as a core value proposition usually outgrows generic middleware, because the limits of someone else’s connector become the limits of your product, and at that point direct control over the data flow stops being optional.
A Practical Salesforce-to-QuickBooks Synchronization Flow
A complete synchronization lifecycle moves through predictable, trackable steps, and writing them out this explicitly is what lets you instrument and debug each one:
- An opportunity reaches a billable status inside Salesforce.
- An event is generated and captured by your event router.
- The integration service identifies the correct SaaS tenant.
- Customer mapping records are validated against the database.
- A canonical billing object is constructed.
- The system searches for the matching QuickBooks customer, or creates one.
- A QuickBooks invoice is generated through the API.
- The assigned QuickBooks invoice ID is stored in the mapping table.
- The integration status updates to successful.
- Salesforce receives the accounting reference and status update.
Every one of those steps is a place to record state, so that when something fails, you know exactly which step it failed on and whether it is safe to retry.
Testing the Integration Before Customers Depend on It
Testing an integration means simulating real-world failures in sandbox environments, not confirming that the happy path works once. Both platforms provide developer sandboxes for exactly this, and Salesforce sandboxes even receive new releases weeks ahead of production, which lets you validate against retirement enforcement before it reaches live orgs.
Run test suites that cover the full OAuth authorization flow, token expiration and refresh cycles, and edge-case field mappings, then deliberately break things. Attempt duplicate record creation to prove your idempotency holds, force API timeouts to confirm safe recovery, delay webhook delivery to test your reconciliation, and trigger rate-limit throttling to verify your backoff behaves. Exercise partial batch failures, disconnected and reauthorized accounts, and large initial data loads against both the Salesforce developer sandbox and the QuickBooks sandbox. The scenarios that matter are precisely the inconvenient ones to reproduce, which is why they have to be deliberately engineered rather than left to chance.
What a Production-Ready SaaS Integration Should Monitor
Shipping to production is the start of the work, not the end. You monitor operational health continuously so you catch problems before customers report them, and the metrics that matter are specific.
Track the synchronization success rate and the count of active failed jobs, along with queue retry frequency and queue backlog depth, so you can see workload building before it becomes a backlog customers feel. Watch webhook delivery failure rates and upstream API response latency to catch third-party degradation early. Because authorization and throttling are your most common failure modes, monitor the frequency of 401 Unauthorized and 429 Too Many Requests responses and your token refresh failure rate directly, rather than inferring them from generic error counts. Measure synchronization time lag so you know how fresh the data actually is, watch per-tenant API consumption so one customer cannot quietly starve the rest, and track reconciliation discrepancy counts as your ground-truth signal of correctness. The integration is healthy only when all of these stay inside stable thresholds, and the moment one drifts is the moment to look, ideally before a customer does.
A Sensible Implementation Sequence
Building this well means following a phased roadmap rather than writing code ad hoc, because several of these layers depend on decisions made in earlier ones.
- Phase 1: Define business workflows and system data ownership.
- Phase 2: Design the multi-tenant database and connection schema.
- Phase 3: Implement secure OAuth authorization and token management.
- Phase 4: Build foundational Salesforce and QuickBooks API clients.
- Phase 5: Construct the intermediate canonical data model.
- Phase 6: Implement one core synchronization workflow end-to-end.
- Phase 7: Add webhooks and event listeners.
- Phase 8: Build the asynchronous queue, retry engine, and idempotency checks.
- Phase 9: Develop automated background reconciliation routines.
- Phase 10: Implement production monitoring and alerting dashboards.
The order is deliberate. You cannot design the schema before you know who owns the data, and building sync workflows before you have idempotency and a canonical model in place just means rebuilding them later.
Critical Questions That Must Be Addressed Before Building the Integration
Teams often rush into code before settling the foundational assumptions, and every one of those assumptions is cheaper to resolve now than to unwind during a scaling crisis. Experienced architects evaluate the operational boundaries first, so that data ownership, synchronization direction, rate-limit strategy, token safety, and error handling are aligned with long-term stability before the first line of code exists.
- Which system is the absolute source of truth for each lifecycle state?
- Which specific records actually require synchronization, and which do not?
- Is the synchronization flow unidirectional or bidirectional?
- Which Salesforce APIs match your expected data volume?
- Which QuickBooks entities does your billing model actually require?
- How will each tenant authorize their Salesforce and QuickBooks connections?
- Where and how will tokens be encrypted and stored?
- How will external IDs map to internal database records?
- How will duplicate records be prevented during network retries?
- What happens when an external API call times out or an event is missed?
Answer these on paper, and you will write far less code, and far better code, than a team that starts at the endpoints.
FAQ
Can a SaaS application connect Salesforce and QuickBooks directly through APIs?
Yes. A SaaS application can build direct API integrations by implementing a dedicated integration layer that manages tenant credentials, mapping logic, queues, and upstream requests independently from the core product. The key is keeping that layer decoupled so upstream changes never reach your primary application.
Which Salesforce API should be used for the integration?
Use the REST API for standard record operations, Bulk API 2.0 for large-volume synchronization jobs, and the Pub/Sub API with Platform Events for event-driven real-time updates. Pin to a current supported version, v67.0 as of Summer ’26, and track Salesforce’s retirement schedule so a deprecated version never breaks you in production.
Does QuickBooks Online use OAuth 2.0?
Yes. QuickBooks Online relies exclusively on OAuth 2.0 for customer authorization, with access tokens that expire after 60 minutes and refresh tokens that rotate, so your token service must always persist the newest refresh token it receives.
Should Salesforce and QuickBooks synchronize in both directions?
Only when there is a strict business requirement for it. Bidirectional sync introduces real complexity around update loops, conflict resolution, and ownership, and it should never be enabled before change-origin tracking, idempotency keys, and timestamp comparisons are in place.
Should a SaaS integration use webhooks?
Yes. Webhooks give you timely change detection, but they must be paired with scheduled reconciliation, because event delivery fails silently. Remember that QuickBooks webhooks carry only a reference payload, so each one triggers a follow-up read that now counts against both your rate limit and your metered read quota.
How should a SaaS application handle API rate limits?
Route work through asynchronous queues, use batch operations where supported, paginate large datasets, respect HTTP 429 responses with exponential backoff and jitter, and track consumption per tenant. Because the QuickBooks limit is 500 requests per minute per realm, one high-volume customer can exhaust its own quota during a single sync, which is exactly why per-tenant monitoring matters more than total traffic.
