✅ API Key Management
Number of keys: Only 3 keys (1 for Gemini and 2 for OpenRouter) — the number is fixed and cannot be changed dynamically.
Usage Mechanism: Switching between keys is done using a round-robin algorithm with intelligent filtering (broken, empty, or paused keys are skipped).
Tracking: Each key has its own log (number of uses, tokens, cost, number of failures, last use, etc.).

⚠️ Failure Handling
After 3 consecutive failures, the key is automatically paused for 5 minutes.
The retry mechanism is based on exponential backoff (2, 4, or 8 seconds).
Automatically switches to another key upon failure.

🛠️ Manual Key Management
A key can be manually disabled from the control panel.
It is immediately removed from use, and its status is saved in the settings.

🔐 API Key Security
Storing keys in server files outside the site folder
Instead of storing keys in the database, you can store them in a secure PHP file outside the public_html or wp-content folder.
Encrypt keys before storing them in the database.
Use openssl_encrypt() or libsodium to encrypt keys, with a private key stored in a file invisible to the user.
Preventing Keys from Being Displayed in the Administration Interface
Ensure that keys:
Do not appear in plugin interfaces.
Do not appear in the console or network during requests (debug info).
Do not be recorded in error or log files.
Add Key Masking to the Administration Interface
If keys must be displayed to the administrator, only show the last four characters and hide the rest.
Blocking Access from External Programs
Use an .htaccess file to block access to key files or paths containing words like key, token, or secret.

🚫 Avoid the following:
Storing keys as plaintext in wp_options.
Embedding keys in JavaScript.
Log keys in debug logs.

Input Processing
When developing this plugin, I used a "prompt text" system that relies on a single template entered into the plugin's backend by the site owner in plain text (within a Textarea).

The suggestion generation method uses a formula such as:
"Write only {3} titles for an educational article on {keyword} in {Arabic}. Do not write any introduction or explanation, just display the titles directly."

Coding Focus Points:

1. Do not rely on any interface that relies on dropdown menus or multiple inputs; just a single command box where the user types everything.
2. Before sending the request to the API, make sure to replace the variable values ​​inside the brackets `{}` with actual values ​​such as the number of suggestions, the keyword, and the language.
3. When receiving a response from the API:
- Remove any lines that begin with phrases like: "Of course," "Here you go," "Here it is," or any unwanted introduction.
- Display only the final results without any additional explanation or commentary.
4. Ensure that the final prompt does not contain general instructions or unnecessary directives; it should be direct and specific.
5. Multilingual support should be provided by replacing `{language}`, with the default language being "English" if no other language is specified.
6. Reduce the number of tokens by keeping the prompt as short and direct as possible.
7. Use simple JavaScript functions to manipulate and replace variables within the sentence before sending it.
8. Maintain a clear separation between:
- Input from the site owner (customizable text)
- Dynamic values ​​entered by the visitor (keyword, number, language)
- Response from the API (cleanable before display)

Primary goal: Send a clean and accurate prompt to the API, receive a response without preamble, and then display the results directly in the UI.

for better integration, follow @openrouter-integration.md and @gemini-developer-api.md and usage-accounting.md.