# One application, or one per client?

If your product serves many companies — an accounting platform, an ERP, a SaaS
where each customer is a separate organisation — you can give **each tenant its
own production application**, with its own `client_id` and `client_secret`.

You can also run everything through a single application. Both are supported,
and the choice is yours.

## What separate applications give you

Each application is its own boundary, so one per tenant means:

- **Separate credentials.** A leaked or rotated `client_secret` affects one
  tenant, not all of them.
- **Its own [webhook](/docs/developer-tools/webhooks-ref) URL**, so events
  arrive already attributed to a tenant instead of needing to be routed after
  the fact.
- **Its own [Pluggy Connect customization](/docs/connect-widget/customization)** —
  company name and logo are set on the application in the Dashboard, so the
  account holder sees the right brand while authorizing their bank.
- **A clean audit boundary.** Items created under one application are reachable
  only with that application's credentials — `GET /items/{id}` with the wrong
  application's key does not return another tenant's Item.

<Callout variant="warning" title="More applications do not mean more request budget">
[Rate limits](/docs/reference/rate-limits) are counted **per endpoint, per IP,
per minute** — explicitly *not* per account and not per API key. Every server
behind the same egress IP shares one budget no matter how many applications it
authenticates as. If you are splitting into one application per tenant to get
more throughput, it will not work; spread the traffic across egress IPs, or
across time, instead.
</Callout>

## What it does not decide

Two things are commercial rather than technical, and they are not the same
question as how you lay out applications:

- Whether the connections included in your plan are counted per application or
  across the account.
- What a second, third or fiftieth production application implies for your
  contract.

Those belong with Sales — [sales@pluggy.ai](mailto:sales@pluggy.ai) or the
WhatsApp on the [pricing page](https://www.pluggy.ai/precos). Ask before you
build the layout around an assumption.

## The consent stays with the account holder

Whichever layout you choose, the person who authorizes the bank connection is
the **account holder**, in their own bank's environment. That does not change
because your customer is a company that serves other companies: an accounting
firm cannot authorize on behalf of the company whose data it reads. Each
account holder connects their own institution through Pluggy Connect, and the
[Item](/docs/connections/item-lifecycle) that results belongs to the application
the connection was created under.