WordPress AI Engine custom endpoint setup

Create a custom AI environment

In WordPress, open Meow Apps > AI Engine > Settings, add an AI environment, and select Custom (OpenAI-Compatible). Meow Apps documents this provider with a base endpoint and an exact model name. Use a staging site while establishing the connection and record your installed plugin version.

Keep the environment dedicated to the drafting task so settings can be reviewed without changing unrelated assistants. Give it a clear local name that identifies the intended endpoint. Before entering credentials, confirm that the administrator session and the configured destination belong to the environments you intend to use.

Set the endpoint, credential and model separately

For an APIsRouter connection candidate, the base endpoint is https://api.apisrouter.com/v1. Use an APIsRouter credential in the plugin's credential field and choose an exact ID from the current catalog whose chat behavior you will verify. Do not paste a full chat-completions URL into a field that expects a base endpoint.

The configuration below is a settings worksheet, not a plugin import file. It deliberately leaves the model as a selection step. Check the current catalog and account access at setup time; a model name typed into a settings field does not establish that the endpoint serves it.

Provider: Custom (OpenAI-Compatible)
Endpoint: https://api.apisrouter.com/v1
API key: enter the gateway credential in the private settings field
Model: select an exact current catalog ID for the test
Initial task: plain-text draft in the administrator workspace

Understand the proposed request path

The custom provider is the model-request boundary. It is not a WooCommerce importer or a permission to publish a product. Keep the first task in a drafting workspace, where the response can be inspected before any store operation is considered.

The diagram shows the proposed APIsRouter connection using the documented provider mechanism. Its model label represents a selection that still needs account and protocol verification. Keep product facts and approval records in your content workflow; do not expect the gateway to know the store's SKU rules, glossary or publication policy.

Check a small draft before adding product data

Use a short synthetic product fact sheet and request a plain-text candidate. Confirm the selected environment and model in the workspace before submitting. Inspect the returned text for completeness and save the result with the plugin version and sanitized configuration.

Next include a protected brand term and an application placeholder, then compare their treatment. Keep the task read-only with respect to store content. Once plain text works, test any additional behavior you actually need, such as streaming or restricted markup, independently. Do not enable extra tools simply because they appear in the interface.

Prepare a product-description candidate from the supplied fact sheet.
Use only the approved facts and brand terminology.
Do not include price, delivery promises or unsupported certifications.
Preserve the supplied product identifier in the review record.
List missing facts separately from the description.
Do not create, edit or publish WordPress content.

Diagnose the failing layer

When a request fails, capture the status, structured error fields and the sanitized request destination. Check the plugin environment before changing model or network settings. Alter one layer at a time so you can identify what fixed the problem.

If a short draft works but a larger task fails, reduce the input and inspect response completeness rather than immediately increasing concurrency. Keep failed attempts in the usage review. Never paste a credential into a public issue, screenshot or command transcript while asking for help.

Add product drafting with a narrow contract

Create a source card with approved specifications, claim references and a glossary. Ask for title, description and review issues as distinct outputs. Keep SKU, prices, currency and measurement units outside editable text patches. A reviewer should see the source and candidate together.

For WooCommerce, route approved content to a separate import preparation step. Confirm the destination fields and multilingual storage layer before mapping the output. Store tools or plugin extensions may add their own capabilities and permissions, so review the specific installed feature before granting access. Keep publishing disabled until that separate workflow is accepted.

Record usage and protect credentials

Track actual request usage alongside the draft and any retries. Keep model calls separate from editor effort, WordPress hosting and plugin licensing. Refer to the current pricing page for gateway charges rather than embedding a price table in a reusable configuration guide.

Restrict access to settings, exports and backups that may contain credentials. For support evidence, retain only the fields needed to diagnose the request. Before an editor uses real catalog data, review what content is sent to the configured endpoint and whether the organization has approved that data path.

Evidence and integration limits

Meow Apps' official guide establishes the Custom (OpenAI-Compatible) setting. The APIsRouter configuration shown here is a proposed use of that setting; a pinned-plugin gateway request and WooCommerce import have not been performed for this article. The diagram is a configuration flow, not a captured execution trace.

To establish compatibility, retain the installed versions, sanitized settings, exact model ID, request result and reviewed draft from a staging test. Add store-write evidence only when that separate operation is authorized and verified. Those records support a precise integration claim without extending a plain-text test to every plugin feature.

FAQ