# Client Configuration

> Reference for all API client fields available in account.diapstash.com.

API clients are created and configured from the **API Access** tab on [account.diapstash.com](https://account.diapstash.com). Each client represents an application that can authenticate users via OAuth 2.0 and access the DiapStash API on their behalf.

## Client Name

The **Client Name** is a human-readable label to identify your client in the dashboard. It is set at creation time and must be at least 8 characters long.

## Client ID

The **Client ID** is a public identifier for your application. It is generated automatically when the client is created and cannot be modified.

It must be included in every API request via the `DS-API-CLIENT-ID` header (see [API Usage](/api/usage#required-headers)).

## Client Secret

The **Client Secret** is used to authenticate your application at the OAuth 2.0 token endpoint.

<note>

The Client Secret is only available when the **Application Type** is set to `API Server`. For `Javascript Web App` clients, there is no client secret — PKCE must be used instead.

</note>

The secret can be regenerated at any time from the client settings. **Regenerating the secret immediately invalidates the previous one**, which may cause existing access tokens to stop working.

## Application Type

The **Application Type** defines the authentication model used by your application.

<table>
<thead>
  <tr>
    <th>
      Label
    </th>
    
    <th>
      Description
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Javascript Web App
    </td>
    
    <td>
      Authentication is performed from the browser using PKCE (e.g. a Single Page App). No client secret is available.
    </td>
  </tr>
  
  <tr>
    <td>
      API Server
    </td>
    
    <td>
      Authentication is handled server-side. The client secret is required and must never be exposed to end users.
    </td>
  </tr>
</tbody>
</table>

<warning>

Never expose the client secret in client-side code. Use the `Javascript Web App` type for browser-based applications.

</warning>

## Logo URL

The **Logo URL** is the URL of your application's logo. It is displayed on the OAuth 2.0 consent screen when users are asked to authorize your application.

Must be a valid URL pointing to an image file.

<note>

This image is shown on the consent screen to confirm which application the user is granting access to their data. Use a logo or icon that represents **your own service** — not a DiapStash logo or icon.

</note>

## Redirect URLs

**Redirect URLs** are the callback URLs to which DiapStash will redirect users after they authorize (or deny) your application.

- At least one redirect URL is required
- Each entry must be a full URL (e.g. `https://myapp.com/callback`)
- Only URLs registered here will be accepted during the OAuth 2.0 flow

## Allowed Origins (CORS)

**Allowed Origins** define which browser origins are permitted to make cross-origin requests to the OIDC endpoints (e.g. the token endpoint).

This is required when your application calls OIDC endpoints directly from the browser (e.g. a SPA exchanging an authorization code for tokens).

- Each entry must be a full origin in the format `scheme://host[:port]` — **without a trailing slash** (e.g. `https://myapp.com`)
- DiapStash domains are always allowed regardless of this setting
- If the field is left empty, a wildcard is applied to public OIDC endpoints only

## Scopes

**Scopes** define the permissions your client is allowed to request when authenticating users.

<table>
<thead>
  <tr>
    <th>
      Scope
    </th>
    
    <th>
      Description
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        cloud-sync.history
      </code>
    </td>
    
    <td>
      Access to the user's change history
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        cloud-sync.stock
      </code>
    </td>
    
    <td>
      Access to the user's diaper stock
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        cloud-sync.types
      </code>
    </td>
    
    <td>
      Access to the user's custom diaper types
    </td>
  </tr>
</tbody>
</table>

<tip>

You will most likely always need the `cloud-sync.types` scope to retrieve the user's custom types.

</tip>

At least one scope is required. The scopes configured here define the maximum set of permissions your client can request. Users will be shown the list of requested scopes on the consent screen before authorizing your application.

For information about how to request scopes during authentication, see the [Authentication](/api/authentication#scopes-permissions) page.

## Pre-filling the client creation form

If you maintain a third-party service that integrates with the DiapStash API, you can link directly to a pre-filled **Create API client** form on `account.diapstash.com`. This makes it easier for developers integrating your service to create a correctly configured client, without having to copy values by hand from your documentation.

<note>

The link only **pre-fills** the form — it never creates the client automatically. The user still has to review the values and submit the form themselves. If the user isn't logged in yet, they will be sent through the DiapStash login first, and automatically brought back to the pre-filled form afterwards.

</note>

The link target is:

```text
https://account.diapstash.com/account/api/create
```

Pre-fill values are passed as query (`GET`) parameters:

<field-group>
<field name="clientName" type="string">

Suggested client name

</field>

<field name="logoUri" type="string">

Suggested logo URL

</field>

<field name="mode" type="string">

Suggested [Application Type](#application-type).

<table>
<thead>
  <tr>
    <th>
      Application type
    </th>
    
    <th>
      Allowed value
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Javascript Web App
    </td>
    
    <td>
      <code>
        spa
      </code>
      
       or <code>
        javascript
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      API Server
    </td>
    
    <td>
      <code>
        backend
      </code>
      
       or <code>
        api-server
      </code>
    </td>
  </tr>
</tbody>
</table>
</field>

<field name="redirectUri" type="array">

Suggested [Redirect URL](#redirect-urls). Repeat the parameter to suggest several values (e.g. `redirectUri=A&redirectUri=B`).

</field>

<field name="allowedOrigin" type="array">

Suggested [Allowed Origin](#allowed-origins-cors). Repeat the parameter to suggest several values.

</field>

<field name="scope" type="array">

Suggested [Scope](#scopes) to request. Repeat the parameter for each scope (e.g. `scope=cloud-sync.history&scope=cloud-sync.types`).

</field>
</field-group>

All parameters are optional, and any unrecognized or invalid value is simply ignored (the corresponding field is left at its default).

**Example**

```text
https://account.diapstash.com/account/api/create?clientName=My+Service&mode=backend&redirectUri=https://myservice.com/oauth/callback&allowedOrigin=https://myservice.com&scope=cloud-sync.history&scope=cloud-sync.types
```