# Create and manage customer sites

A **site** is the customer organization within a reseller. Sites define which
services and features the organization can use, how usage is billed, and how
users are configured.

Site provisioning is API-first. Create and configure sites through the Namirial
Notify Core API, then manage site-level operations from the site
administration UI.

## Provisioning channel (Core API)

Site provisioning and configuration are performed through endpoints under the
`/sites` resource, including:

- `POST /sites` to create a site.
- `PATCH /sites/{siteId}` to update site-level attributes.
- `GET/PATCH /sites/{siteId}/config` to manage site configuration values.
- `GET/PATCH /sites/{siteId}/features` and per-service feature endpoints to
manage enabled capabilities and defaults.


## Required fields

When creating a site, the following fields are mandatory:

| Field | Description |
|  --- | --- |
| **Display name** | Human-readable organization name |
| **Name** | Unique URL-safe identifier for the site (see [naming rules](#site-name-rules)) |
| **Email** | Primary contact email for the organization |
| **VAT number** | Fiscal or tax identification number |
| **Billing mode** | How usage is accounted (see [billing modes](#billing-modes)) |
| **Reseller** | The reseller this site belongs to |


## Optional fields

| Field | Description |
|  --- | --- |
| Country | ISO country code for the organization |
| Culture | Default locale for the site (e.g. `en-US`, `es-ES`) |
| Phone | Contact phone number |
| Address, locality, region, postal code | Physical address |
| Monthly credit limit | Maximum credits that can be consumed per month |
| User email addresses limit | Maximum number of sender email addresses per user (default: 10) |
| Invoicing email | Email for monthly invoice reports (required when invoice reports are enabled) |
| Notaries | Notary identifiers associated with the site |


## Site name rules

The `Name` field is the site's unique identifier and is used to route requests.
It must:

- Match the pattern defined by the platform constraints.
- Not be one of the reserved names. Reserved names include: `api`, `www`,
`help`, `mail`, `smtp`, `app`, `root`, `global`, `status`, `support`, and
others that are reserved for system use.


Site names should be treated as immutable after provisioning. Choose a stable,
meaningful identifier.

## Billing modes

The following billing modes are available:

| Identifier | Description |
|  --- | --- |
| `BySubmission` | Credit-based billing differentiated by service type. Consumption is tracked against contracted credits. (default) |
| `PrePaid` | Credits are purchased in advance and deducted on use |
| `PostPaid` | Usage is invoiced retrospectively |
| `FlatRate` | Flat-rate billing |
| `Volume` | Billing by transaction volume |


The batch sending feature flags (`EviMailBatch`, `EviSmsBatch`,
`EviNoticeBatch`) are incompatible with all non-`BySubmission` billing modes
and cannot be enabled together.

## Enabled services

Each service must be explicitly enabled per site. Disabling a service prevents
users on that site from sending or accessing it, including through the API.

| Capability | Service |
|  --- | --- |
| Enable EviMail | Certified email |
| Enable EviSMS | Certified SMS |
| Enable EviNotice | Certified electronic notification |
| Enable EviSign | Electronic signature |
| Enable EviPost | Certified postal notification |
| Enable API | Programmatic access via the REST API |


## Reporting options

| Option | Description |
|  --- | --- |
| Enable reports | Allows users with the `ReportAdmin` role to generate transaction reports |
| Enable FTP report | Enables scheduled delivery of reports to an FTP destination at the configured time |
| FTP export time | Time of day at which the FTP report is generated (HH:MM) |
| Enable invoice report | Sends a monthly invoice report to the invoicing email |


## Feature flags

Feature flags control advanced capabilities per site. The following flags are
available:

| Flag | Description |
|  --- | --- |
| `SecondFactorAuthentication` | Enables two-factor authentication for site users |
| `DefaultLanguageLegacy` | Uses the legacy default language (`es`) for affidavits and notifications |
| `NewUi` | Opts the site into the updated web interface |
| `CertificationLevelsLegacy` | Enables legacy certification level identifiers |
| `EviMailBatch` | Allows batch EviMail sending |
| `EviSmsBatch` | Allows batch EviSMS sending |
| `EviNoticeBatch` | Allows batch EviNotice sending |
| `EviNoticeWithRcs` | Enables RCS channel for EviNotice |
| `EviSmsWithRcs` | Enables RCS channel for EviSMS |
| `EviNoticeWhatsApp` | Enables WhatsApp channel for EviNotice |
| `EviSignWhatsApp` | Enables WhatsApp channel for EviSign |
| `EviMailLtaStorage` | Enables long-term archiving (LTA) for EviMail |
| `EviSmsLtaStorage` | Enables LTA storage for EviSMS |
| `EviNoticeLtaStorage` | Enables LTA storage for EviNotice |
| `EviSignLtaStorage` | Enables LTA storage for EviSign |
| `EviPostLtaStorage` | Enables LTA storage for EviPost |


## Long-term archiving (LTA)

When any LTA storage flag is enabled, the site must also provide:

- **LTA company ID** — the organization identifier in the LTA system.
- **Per-service LTA document ID** — one document identifier for each service
with LTA enabled (`LtaEviMailDocumentId`, `LtaEviSmsDocumentId`,
`LtaEviNoticeDocumentId`, `LtaEviSignDocumentId`, `LtaEviPostDocumentId`).


Enabling an LTA flag without the corresponding document ID will fail validation.
All LTA document IDs must be set before enabling the flags.

## QERDS profiles

For sites that require Qualified Electronic Registered Delivery Service (QERDS)
certification levels:

- **QERDS profiles** — semicolon-separated list of profile identifiers. Each
value must contain `::`; two-part and three-part values such as
`Provider::ProfileName` or `Provider::ProfileName::Customer` are valid when
configured for the identity provider.
- **QERDS identity tenants** — semicolon-separated list of identity tenant
identifiers in the format `tenantId@certLevel`.


Configure QERDS profiles for QERDS enrollment flows, and configure QERDS identity tenants when tenant-specific QERDS identity validation is used.

## Site lifecycle

Sites progress through the following statuses:

| Status | Description |
|  --- | --- |
| `Pending` | Site has been created but not yet activated |
| `Active` | Site is operational and users can log in |
| `Disabled` | Site has been deactivated; users cannot log in |
| `Deleting` | Site is scheduled for removal |


Deleting a site is irreversible. Verify that all user data and transaction
history have been archived or exported before initiating deletion.

## Credit management

Credit limits and adjustments are managed through site provisioning and
configuration flows. The monthly credit limit defines the maximum credits that
can be consumed per month. Contact your Namirial representative for details on
how this limit applies to your billing mode.

## Related

- [Deployment overview](/products/namirialnotify/deployment)
- [Reseller customization](/products/namirialnotify/deployment/reseller-customization)
- [Multi-site configuration](/products/namirialnotify/deployment/sites-customization)
- [Customer information and reporting](/products/namirialnotify/deployment/customer-information)