# Authentication and account boundaries

Create an API key in **Developers → API Keys** while signed into the account and store you want to use. The secret is displayed at creation or regeneration. Keep it in your client’s private credential configuration.

Save the full secret from the confirmation screen. Key lists show only a masked display value, such as `smsred_••••1234`; that value cannot authenticate. If clipboard access is blocked, select and copy the full key manually before closing the confirmation. Create a new key if the old full secret was not saved. Regenerating a key invalidates its previous secret.

Send one of these headers on every API request:

```http
X-API-Key: YOUR_STORE_API_KEY
```

```http
Authorization: Bearer YOUR_STORE_API_KEY
```

REST authentication accepts case-insensitive `Bearer` schemes and HTTP whitespace around credentials. An empty `X-API-Key` does not override a valid Authorization header. A nonempty `X-API-Key` takes precedence; send one credential header when possible.


A key grants access to one account on one store. The server binds the account from the key; no developer request accepts an `accountId`, tenant, site or reseller selector. Use a reseller store's origin for its keys. A primary TextVerified key is not a reseller-store key. Message requests require ownership of the associated order.


Unauthenticated or revoked keys fail authentication. A valid key presented to the wrong store also fails. Rotate the client configuration after regenerating a key.

REST authentication failures return HTTP401 with `message: "Unauthorized"`, plus `code`, `hint` and `requestId`. Codes are `API_KEY_MISSING`, `API_KEY_FORMAT`, `API_KEY_MASKED`, `API_KEY_INVALID` and `API_KEY_STORE_MISMATCH`. The same reference is returned in `X-Request-ID`. Invalid/inactive keys remain rejected. Server diagnostics record the reason and reference without credentials, key hashes, request bodies or query strings.

[Documentation index](https://textverified.org/en/store-docs/index)