---
read_when:
    - Написання документації, що містить токени, ключі API або фрагменти облікових даних
    - Оновлення прикладів, які можуть скануватися інструментами виявлення секретів
summary: Умовні позначення заповнювачів, безпечні для сканера секретів, для документації та прикладів
title: Умовні позначення заповнювачів секретів
x-i18n:
    generated_at: "2026-06-27T18:18:35Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 87e0db9ad47bf0c9d434da9bdcd6587e0b01d4eddf5ad245cf3dc87a1d166875
    source_path: reference/secret-placeholder-conventions.md
    workflow: 16
---

# Умовні позначення заповнювачів для секретів

Використовуйте заповнювачі, які зрозумілі людині, але не схожі на справжні секрети.

## Рекомендований стиль

- Надавайте перевагу описовим значенням, як-от `example-openai-key-not-real` або `example-discord-bot-token`.
- Для фрагментів shell надавайте перевагу `${OPENAI_API_KEY}` замість вбудованих рядків, схожих на токени.
- Залишайте приклади очевидно фальшивими й обмеженими конкретною метою (провайдер, канал, тип автентифікації).

## Уникайте цих шаблонів у документації

- Буквальний текст заголовка або нижнього колонтитула приватного ключа PEM.
- Префікси, схожі на реальні облікові дані, наприклад `sk-...`, `xoxb-...`, `AKIA...`.
- Bearer-токени реалістичного вигляду, скопійовані з runtime-журналів.

## Приклад

```bash
# Good
export OPENAI_API_KEY="example-openai-key-not-real"

# Better (when the doc is about env wiring)
export OPENAI_API_KEY="${OPENAI_API_KEY}"
```