# Reseller customization

A **reseller** is the top-level organizational unit in Namirial Notify. Each
reseller represents a branded instance of the platform and owns one or more
customer sites. Reseller configuration controls the visual identity,
communication defaults, and service capabilities available to all sites under
that reseller.

## Identity fields

Each reseller has the following core identity properties:

| Field | Description |
|  --- | --- |
| **Name** | Unique internal identifier for the reseller |
| **Domain** | Web domain used for the reseller's application (e.g. `notify.example.com`) |
| **Email domain** | Domain used for platform-sent email (e.g. `example.com`) |
| **External ID** | Optional external reference identifier |
| **Legal ID** | Optional legal or tax identifier |


## Branding and theme

Each reseller defines a visual theme applied across the web interface and
outbound communications.

Reseller theme values are currently managed operationally through database
configuration, not through a self-service reseller UI.

| Attribute | Description |
|  --- | --- |
| **Theme logo** | Binary image used as the service logo |
| **Primary color** | Main brand color (hex or CSS value) |
| **Secondary color** | Supporting brand color |
| **Success color** | Color used for success states |
| **Info color** | Color used for informational states |
| **Warning color** | Color used for warning states |
| **Danger color** | Color used for error or danger states |


## Service settings

Reseller-level settings provide defaults for all sites in the reseller. The
exact override precedence depends on your deployment configuration. Contact
your Namirial representative to confirm which settings are configurable for
your reseller environment. The following settings are defined in the reseller
configuration:

Reseller configuration is API-first. Use Core API endpoints under
`/resellers/{name}` (for example config and feature endpoints) to manage
supported reseller settings.

### Identity and communication

| Setting key | Description |
|  --- | --- |
| `ApplicationUrl` | Base URL of the reseller web application |
| `ApplicationEmail` | System email address for the reseller instance |
| `SupportEmail` | Support contact address shown to users |
| `CommsEmail` | Address used for general platform communications |
| `ServiceName` | Display name for the white-labeled service |
| `CompanyLegalName` | Legal name of the operating company |
| `CompanyLegalId` | Legal or tax identifier of the operating company |
| `CompanyLegalRegInfo` | Legal registration details |
| `ProgressNotificationsEmail` | Email address used for platform progress notifications, if configured. |


### Email (EviMail)

| Setting key | Description |
|  --- | --- |
| `EviMail:DefaultFromAddress` | Default FROM address for outbound EviMail messages |
| `EmailAddSender` | Whether sender address is included in outgoing email |
| `EmailOverrideFrom` | Whether the FROM address can be overridden at send time |


### SMS (EviSMS)

| Setting key | Description |
|  --- | --- |
| `EviSmsDefSourcePhone` | Default source phone number for EviSMS |
| `EviSmsForwardProfile` | SMS forwarding profile identifier |
| `EviSmsHeader` | Text prepended to outbound SMS bodies |
| `EviSmsFooter` | Text appended to outbound SMS bodies |
| `EviSms:RcsSendProfile` | RCS send profile for EviSMS (when RCS is enabled) |


### EviNotice

| Setting key | Description |
|  --- | --- |
| `EviNotice:SmsProfile` | SMS delivery profile for EviNotice |
| `EviNotice:SourcePhone:Default` | Default source phone for EviNotice SMS |
| `EviNotice:AddSender` | Whether the sender is included in EviNotice communications |
| `EviNotice:OverrideFrom` | Whether the FROM can be overridden for EviNotice |
| `EviNotice:RcsSendProfile` | RCS send profile for EviNotice (when RCS is enabled) |


### EviSign

| Setting key | Description |
|  --- | --- |
| `EviSignProfile` | Signature profile identifier for EviSign |


### Authentication and security

| Setting key | Description |
|  --- | --- |
| `MobilePinProfile` | Profile used for mobile PIN delivery |
| `WhatsAppProfile` | Profile used for WhatsApp PIN delivery |
| `System:SecondFactor:Email:Template` | Template for second-factor authentication requests |


### Legal and compliance links

These settings are locale-aware. A key such as `FloatFooter` accepts both a
default value (culture `*`) and culture-specific overrides (e.g. `en`, `es`,
`it`, `de`, `fr`, `pt`, `ca`, `ro`).

| Setting key | Description |
|  --- | --- |
| `CookiesPolicyUrl` | URL to the reseller's cookie policy page |
| `GeneralDataProtectionRegulation` | URL to the GDPR information page |
| `GeneralLegalTermsUrl` | URL to the general terms and conditions |
| `NewUserAgreementUrl` | URL to the user registration agreement |
| `FloatFooter` | HTML or text content for the floating footer shown across the web UI |
| `EviNotice:QERDS:ES:TermsAndConditions:Acceptance:Text` | QERDS terms acceptance text for Spain (per locale) |
| `EviNotice:QERDS:IT:TermsAndConditions:Acceptance:Text` | QERDS terms acceptance text for Italy (per locale) |


## Enabled certification levels

Resellers can restrict which certification levels are available on their sites.
Certification levels can be configured per service:

- EviMail certification levels
- EviSMS certification levels
- EviNotice certification levels
- EviSign certification levels
- EviPost certification levels


Restricting available levels at the reseller prevents sites from enabling
certification levels the reseller is not contractually authorized to offer.

## White-label linkage

A reseller can be associated with a white-label configuration via the
`WhiteLabelId` attribute. This links the reseller to an external white-label
record used for additional branding or integration configuration.

## Forwarding domains and email authentication

To allow sites under a reseller to send EviMail from custom sender addresses,
each sender domain must be registered and verified at the site level. Domain
verification requires the DNS records provided during onboarding to be in place.

The specific DNS records required for your deployment — including SPF include
entries and DKIM CNAME records — are provided by your Namirial representative
during onboarding. The domain verification UI guides you through verifying that
the required records are in place.

Alternatively, a custom DKIM selector can be registered. The platform returns the TXT record value containing the public key.

Domain verification is performed in the site administration UI under the domain
management section. Only site administrators can register domains. Domain status values include `Active`, `New`, `Failed`, `Disabled`, `Deleting`, and `Legacy`. In the UI, `New` may be shown as Pending and `Deleting` may be shown as Pending removal. Domains can be used for sending only when their source state allows sending.

## Related

- [Deployment overview](/products/namirialnotify/deployment)
- [Create and manage customer sites](/products/namirialnotify/deployment/create-customer-site)
- [Multi-site configuration](/products/namirialnotify/deployment/sites-customization)