# Portals and environments

This page is the reference for where Peach runs and how you reach it: the API hosts for each environment, how sandbox differs from production, and the three web portals Peach provides alongside the API. Use it to identify the correct host to call and to understand which portal your teams use for which job. For the credentials you send to these hosts, see [Credentials and access](/getting-started/credentials-and-access).

## Environments

Peach exposes the same API across separate environments. Each environment has its own base URL; the credentials and the loan type IDs you use are scoped to the environment they were issued for.

The public API specification declares a single server — the sandbox host. The production host is provided to you during onboarding and is not fixed by the public specification.

| Environment | Base URL | What it is for |
|  --- | --- | --- |
| Sandbox | `https://sandboxapi.peach.finance/api` | Integration and testing against non-production data. Use this host while you build and verify your integration. |
| Production | Provided during onboarding | Live borrowers, loans, and money movement. |


Send every request to the host for the environment you are working in. A key issued for sandbox does not authenticate against production, and the reverse holds as well — see [Credentials and access](/getting-started/credentials-and-access).

## How sandbox differs from production

What the specification settles is the base URL: sandbox and production are reached at different hosts, and the request and response contracts are otherwise the same across both. Behavioral differences beyond the host — how long test data is retained, whether rate limits differ, and which external integrations are stubbed rather than live — are operational properties that the specification does not fix.

Sandbox is provisioned for you by Peach and provided to you during onboarding. You cannot reset the sandbox yourself, and there is no public API endpoint to create, seed, or reset one.

For the canonical test values — cards, bank accounts, and test-borrower data — that are valid only in sandbox, see [Sandbox and test data](/getting-started/sandbox-and-test-data).

## Portals

Beyond the API, Peach provides web portals for the people who operate and use your program. Each portal serves a distinct audience.

| Portal | Who uses it | What it is for |
|  --- | --- | --- |
| Admin Portal | Your configuration and engineering teams | Configure and inspect your program, including loan types and roles. |
| Agent Portal | Your servicing and collections agents | Service accounts and manage borrower relationships. |
| Borrower Portal | Your borrowers | White-label self-service for borrowers to view and manage their loans. |


The platform also defines a Help domain type for support-facing content. It is not part of the core three-portal integration model and is not covered here.

Portal hostnames are configured per company. Each portal address is stored against your company in Peach and resolved to your company and portal type when the portal loads, rather than following a fixed public subdomain pattern. Your portal URLs are provided to you during onboarding.

The addresses Peach provisions for you follow a consistent naming form. In sandbox, they are `companyName-admin.peach-sandbox.finance`, `companyName-agent.peach-sandbox.finance`, and `companyName-borrower.peach-sandbox.finance`; the production addresses are the same names with `-sandbox` removed. This is the form of the URLs Peach hands you, not a pattern the platform enforces — as described above, each hostname is resolved per company, so use the addresses you are given rather than assuming this shape.

## Portal authentication

The portals use portal and session authentication, not your API key. The API specification declares `oauth2` and `bearerAuth` schemes that back this session-based access, distinct from the `apiKeyHeader` (`X-API-KEY`) scheme your application uses to call the API. You do not use your API key to sign in to a portal, and portal sessions do not authenticate API requests.

For the API key itself and how it authenticates your requests, see [Credentials and access](/getting-started/credentials-and-access).

## See also

- [Credentials and access](/getting-started/credentials-and-access) — The API key, `companyId`, and loan type IDs you send to these hosts.
- [Sandbox and test data](/getting-started/sandbox-and-test-data) — The canonical test values that work only in sandbox, next in the setup sequence.
- [Core concepts](/getting-started/core-concepts) — The borrowers, loans, and loan types your program is built from.