AI Integration Prompts

Copy a prompt into an AI coding assistant that can inspect your project, read documentation and run tests. Each code block has a copy button in its top-right corner.

How to Use

1. Open your existing project in your coding assistant.
2. Choose a development template and replace bracketed fields. Write "unconfirmed" where necessary.
3. Let the assistant inspect, implement and test. Use the acceptance prompt afterward.

Never paste keys, Bot tokens, Webhook secrets or passwords into prompts. Use deployment Secrets or untracked server-side environment variables. Using an AI coding assistant does not require enabling or buying Open4X AI Model Gateway.

Delivery boundary

A prompt does not provision services or guarantee production readiness. Credentials, quotas, domains, provider authorization and releases require configuration and approval. If documentation is inaccessible, request non-secret official documentation instead of guessing interfaces.

Already Integrated: Role Checks

Already integrated chat but seeing incorrect behavior? Use Widget Role Checks: customer, website agent, merchant administrator/Console, or embed/origin failures. These standalone prompts separate credential, routing and UI problems without rebuilding the integration.

Template 1: Service Integration

Use for AI Gateway, Bot, Webhook Push or integration assessment.

Act as this project's integration engineer. Implement Open4X with code and tests, not just a proposal.

Project context:
- Project/business name: [fill in]
- Services and workflow: [AI questions, Telegram notifications, Webhook Push, etc.]
- Frontend, backend, hosting: [fill in or inspect]
- Verification environment: [local / authorized staging; mock if unconfirmed]
- Required workflow: [fill in]
- Out of scope: [fill in]
- Authorized spending and external effects: [default: no paid calls or real messages]

Inspect architecture, authentication, configuration, tests and deployment conventions. Preserve existing changes and reuse project patterns.
Read these official sources and follow the relevant service documentation:
https://docs.open4x.com/guide/customer-integrations
https://docs.open4x.com/guide/api-reference
https://docs.open4x.com/openapi/open4x.openapi.json
https://docs.open4x.com/guide/connected-accounts
https://docs.open4x.com/guide/pricing-billing
https://docs.open4x.com/guide/security-operations

Requirements:
1. Identify actual endpoints, authentication, scopes, Service Alias, fields and limitations. Record URLs, retrieval date and specification version when available. Conflicts or inaccessible documents are blockers; do not invent APIs, SDKs, npm packages or prices.
2. https://api.open4x.com is production, not a default test endpoint. Match staging URLs, tenant and keys from one delivery package. Missing configuration means mock-only, never silently switch to production.
3. Keep secrets server-side. Do not read or print existing secret values or request them in chat. Provide placeholder-only examples and Secrets configuration instructions. Use minimum scopes, not unrestricted keys to bypass 403.
4. The merchant owns users, orders, permissions and financial actions. Frontends call protected merchant backend routes. Manage provider credentials in Connected Accounts.
5. Follow each endpoint's contract for idempotency, timeouts, retries, limits and async results. Not every write is idempotent. Never blindly retry uncertain writes. Preserve request_id with redacted logs.
6. Implement loading, success, failure, timeout, quota and fallback states. Open4X outages must not block existing login, orders or payments.
7. Deliver a minimal complete workflow without unrelated refactoring. Explain necessary database changes with migration/rollback; do not promise every integration requires no database changes.
8. Run local tests. Real provider tests require explicit authorization, resources and spending limits. Production deployment requires separate approval.

Deliver code, configuration instructions, a minimal example, actual test results, usage instructions, rollback and completed/pending/unverified items. Distinguish mock, staging and production evidence. Start inspecting; ask only genuinely blocking questions.

Template 2: Website Support Chat

Default scope: authenticated website user, Widget and human reply from the hosted Open4X workbench. Telegram, AI and ticket synchronization need separate scope and acceptance.

Implement Open4X website support chat in this project, with code, tests and merchant handover instructions.

Project context:
- Website name and domain: [fill in]
- Stack and hosting: [fill in or inspect]
- User authentication: [fill in or inspect]
- Use case: [general support / order support / buyer-author inquiry]
- Operator workbench: [default: Open4X hosted workbench]
- Environment: [local or authorized staging; mock if unconfirmed]
- Fallback: [existing ticket page or contact channel]

Inspect the project and read these official sources and referenced API/SDK protocols:
https://docs.open4x.com/guide/merchant-chat-quickstart
https://docs.open4x.com/guide/support-integration
https://docs.open4x.com/guide/conversation-hub
https://docs.open4x.com/guide/conversation-administration
https://docs.open4x.com/openapi/open4x.openapi.json

Use current Conversation Hub contracts, not legacy Bot Session APIs. List actual endpoints/fields and record versions and retrieval date. Treat conflicts, missing versions or unavailable SDKs as blockers; never guess packages or initialization/destruction methods.

Requirements:
1. Implement protected POST /api/open4x/session in the merchant backend. This is a merchant-owned route. Derive identity from real server sessions, enforce CSRF/Origin checks and rate limits, and distrust browser-provided identity, roles and recipients.
2. Use a dedicated server-side Bridge Key with conversation:read and conversation:write from Console > API Keys. Add conversation:events:write only for event Webhook management/replay. Never give browsers a Bridge Key or conversation:supervise permissions.
3. Use documented POST /v1/conversations to create/reuse a conversation with a stable external_conversation_id. Match returned active participant IDs and roles. Reject missing, ambiguous or inactive participants, never fall back to broadcasting.
4. Use documented POST /v1/conversations/{id}/widget-session. Set participant_id and recipient_participant_ids server-side. TTL is 900-3600 seconds, default 1800. Return only necessary short-lived token and expiry to the current visitor with no-store. Never log tokens or put them in shared caches.
5. Integrate a confirmed Loader/SDK version with loading, failure and fallback states. Follow documented expiry, reauthentication, logout and account switching. Do not assume a refresh API exists. Use a confirmed integration method or flag missing SDK delivery.
6. Production uses https://api.open4x.com, https://widget.open4x.com and https://console.open4x.com. Do not pair them automatically with staging keys. Match the full environment package; do not substitute workers.dev domains.
7. Configure HTTPS, CSP and CORS. Never expose keys, disable security or allow all origins to fix CORS. Provide secret-free configuration examples and server Secrets instructions.
8. Operators join at https://console.open4x.com/dashboard/conversations and send public replies to explicit customers. Internal notes must not reach customers. Check order authorization before order support; multi-party participation does not imply visibility of all messages.
9. AI stays off with no data sent to models. Do not automatically enable Telegram or real providers. Outages must leave login, payments and existing tickets working, with the configured fallback visible.
10. Reuse identity data for minimal chat. Add persistence when mapping, outbox, deduplication or reconciliation requires it; process memory is not durable synchronization. Retry only under actual idempotency contracts.

Test both message directions, refresh history, reconnect, two-user isolation, internal-note isolation, expiry/logout/account switch, outage fallback and the full flow with AI off. Mocks are not real acceptance; real sends and production deployment need separate authorization.

Deliver changes, configuration checklist, operator instructions, test evidence and blockers. Never request plaintext keys, print tokens or claim unexecuted tests passed. Start inspecting the project.

Template 3: Acceptance Review

Run after implementation. This does not authorize real messages, paid calls or production deployment.

Independently review this project's Open4X integration. Earlier completion claims are not evidence.

Inspect code, configuration examples and tests against:
https://docs.open4x.com/guide/merchant-chat-quickstart
https://docs.open4x.com/guide/security-operations
https://docs.open4x.com/openapi/open4x.openapi.json

Check server-only secrets, tenant/user isolation, business authorization, recipients, internal notes, conversation/token lifecycle, environment matching, idempotency/retries and fallback. If Webhooks are included, check raw-body signature verification, time windows, durable deduplication and compensation. Mark unused modules not applicable.

Run available local tests. Real provider calls, messages, spending and production deployment require separate authorization. Inspect secret configuration status only, never values. Mark unverifiable API/SDK behavior unverified.

Report issues by severity with file locations, executed tests, mock/staging/production distinction and skipped tests with reasons. Conclude: ready for further integration testing / integration blocked / ready to request production acceptance. Health checks and HTTP 200 do not prove business acceptance. Do not declare SLA, pricing or compliance terms frozen without evidence.

Merchant Responsibilities

Merchant confirms	AI assists with
Tenant, environment, secure keys, actual quotas and cost ceiling	Integration, configuration examples, error handling and tests
User/order/author permissions and operator ownership	Existing auth, explicit recipients and least privilege
Domains, provider authorization and callback endpoints	Protocols, deployment instructions and controlled tests
Real acceptance and release approval	Evidence, remaining work and rollback

Prompts do not replace pricing, retention, DPA or SLA agreements. Complete merchant acceptance and service-specific tests before handover.