# AI implementation prompts for Boring Order Tracker integrations Canonical human-readable page: This prompt pack helps an integration operator design and implement its own backend against the Boring Order Tracker (BOT) Operator Integration API v1. It is implementation assistance, not an API credential, a production approval, or permission to access data. The OpenAPI 3.1 contract, AsyncAPI contract, operator guide, field catalogue, and consent/revocation guide published on the BOT integration portal remain authoritative. The current BOT Integration Terms are published at . Current rollout boundary: the operator portal and synthetic sandbox are available. Production individual data remains closed until the mobile app's per-integration, per-resource consent and complete initial synchronization are released and every legal and operational production gate has passed. The reference integration remains pull-only with a 15-minute polling cadence; signed webhooks are an optional later enhancement, never the recovery source. ## Non-negotiable boundary for every prompt Every generated implementation must: - use only documented BOT Operator Integration API v1 operations; - use synthetic sandbox data until BOT manually approves production access and issues a separate production client certificate; - authenticate the machine API with the environment-matching mTLS certificate, while continuing to validate BOT's normal public HTTPS certificate; - process only resources currently and explicitly shared with that integration; - never request, infer, scrape, log, store, return, or derive a VIN, a real order number, a BOT account identifier, contact/address/payment/financing data, Tesla identifiers or credentials, raw provider responses, or undocumented fields; - never use internal BOT or mobile-app interfaces, bypass mTLS or review gates, broaden scopes, correlate identifiers across integrations, or treat sandbox approval as production approval; - treat revocation as immediate loss of access, erase retained individual and derived data, and acknowledge deletion only after it has really completed. - require explicit acceptance of the current BOT Integration Terms before an integration is created and a new explicit acceptance for every later terms version; - treat the standard licence as non-commercial only: ads, Google AdSense, sponsorships, affiliate revenue, subscriptions, paid access, lead generation, data licensing/resale, and every other direct or indirect monetization require an individual written BOT agreement before use; - display a conspicuous BOT credit and app link wherever BOT data appears and, when sources are mixed, label every BOT-derived dataset, record, entry, chart series, or result directly at its output point rather than relying on a footer. Replace bracketed placeholders before using a prompt. Give the AI the downloaded OpenAPI/AsyncAPI files and the relevant canonical guides as input. Review and test generated code; AI output never changes the scopes BOT approved. ## Required BOT footer credit Copy the versioned, tracker-free credit into the public footer: ```html
``` The script renders a compact rendition of the original BOT app logo and the text “Data provided by Boring Order Tracker with user consent”. It sets no cookies, contains no analytics, and makes no background requests other than loading the versioned script and BOT logo. Keep `referrerpolicy="no-referrer"` so the partner page URL is not sent with the asset request. `data-bot-theme` accepts `auto`, `light`, or `dark`. The placeholder may be omitted when the script itself is placed directly in the footer; repeated execution is idempotent. This badge supplies the site-wide footer credit only. It does **not** replace point-of-display attribution for mixed-source output: every BOT-derived record, table value, map point, chart value, and export must still be labelled directly where it is displayed. A footer alone is not enough. ## Prompt 1: architecture and threat-boundary plan ```text You are designing an operator-owned backend for a Boring Order Tracker (BOT) integration. Use the supplied BOT OpenAPI 3.1 contract, operator guide, field catalogue, and consent/revocation guide as the only source of truth. Target stack: [LANGUAGE, FRAMEWORK, DATABASE, QUEUE/CACHE] Deployment environment: [HOSTING/CONTAINER PLATFORM] Requested BOT scopes: [APPROVED OR REQUESTED SCOPES] Product feature: [WHAT THE OPERATOR SITE WILL DO] Produce an implementation-ready architecture covering: the browser/operator boundary, BOT mTLS client boundary, secret/key storage, initial and delta pull sync, local idempotent persistence, exact-order linking, history pagination, revocation deletion and acknowledgement, optional webhook recovery, rate-limit handling, audit/observability without sensitive payloads, and sandbox-to- production separation. Include a data-flow diagram in Mermaid, a component table, storage schema, failure/recovery paths, and a phased delivery checklist. Include a licence and attribution boundary. The standard BOT integration licence is non-commercial only. Treat ads, Google AdSense, sponsorships, affiliate revenue, subscriptions, paid access, lead generation, resale/data licensing, and any other monetization as commercial and block go-live unless an individual written BOT agreement covers it. Require current-version terms acceptance before integration creation and after every terms update. Require a prominent BOT credit/app link, and label every BOT-derived record, entry, series, or result directly where mixed-source output displays it. Privacy and authorization constraints: process only resources explicitly shared with this integration. Never request, infer, scrape, log, store, return, or derive a VIN, real order number, BOT account identifier, contact/address/ payment/financing data, Tesla identifiers or credentials, raw provider responses, or undocumented fields. Never use internal BOT/mobile interfaces, bypass mTLS or manual production review, broaden scopes, correlate IDs across integrations, or treat sandbox approval as production approval. Pull sync is the canonical recovery path. Call out any requested feature that the supplied contract does not authorize instead of inventing an endpoint or field. ``` ## Prompt 2: typed OpenAPI client and safe service wrapper ```text Implement a typed client and a small domain-facing service wrapper for the BOT Operator Integration API v1 in [LANGUAGE/FRAMEWORK]. Generate or validate types from the supplied OpenAPI 3.1 file; do not invent operations or response fields. The base URL is configured per environment and credentials are filesystem paths or secret-store handles for the matching client certificate and private key. Support GET /capabilities, POST /link-codes/redeem, GET /sync, order and vehicle snapshot/history reads, GET /statistics/orders, and POST /revocations/{id}/ack only when their scopes are present. Implement mTLS while still validating BOT's public HTTPS hostname/CA, strict timeouts and response- size limits, RFC 9457 application/problem+json decoding with request_id, ETag/ If-None-Match and 304, opaque cursors, pagination, Retry-After on 429, and bounded exponential backoff for retryable 503/network failures. Never retry unsafe POSTs without the endpoint's documented idempotency behavior. Add sandbox contract tests and show configuration without embedding secrets. Privacy and authorization constraints: accept and persist only schema fields that the approved profile returns. Never request, infer, scrape, log, store, return, or derive a VIN, real order number, BOT account identifier, contact/ address/payment/financing data, Tesla identifiers or credentials, raw provider responses, or undocumented fields. Redact bodies, link codes, certificates, keys, cursors, and resource IDs from routine logs. Do not disable TLS checks, use internal BOT/mobile interfaces, bypass production review, or reuse sandbox credentials in production. If the contract and my request conflict, stop and explain the conflict. ``` ## Prompt 3: mTLS key, CSR, P12, and rotation runbook ```text Write a secure, platform-specific runbook for BOT mTLS enrollment and rotation on [OPERATING SYSTEM/SECRET STORE/REVERSE PROXY]. Base it only on the supplied BOT mTLS certificate guide and the environment, client ID, and exact CSR common name supplied by BOT during the certificate issuance flow. If BOT has not supplied those values, stop and request them; never guess an identity. Cover local private-key generation, a CSR with BOT's supplied common name in the form bot::, accepted RSA 3072-8192 or EC P-256/P-384 keys, file ownership and permissions, secret backup policy, certificate/chain install, a harmless /capabilities handshake test, monitoring the 90-day expiry, rotation with at most two active certificates during the documented 14-day overlap, and immediate revocation/incident steps. Also describe the one-time encrypted P12 comfort flow as an alternative whose package/password must be claimed within 15 minutes and stored immediately in the operator's secret store. Never output or ask me to paste a private key, P12 password, certificate claim token, or live credential into chat, source control, logs, CI artifacts, or command history. Do not disable server-certificate/hostname validation, fabricate a CSR identity, request a production certificate before BOT approval, reuse a sandbox certificate in production, or suggest bypassing mTLS, portal reauthentication, certificate status checks, or production gates. The API never authorizes VIN, real order number, BOT account/contact/address/payment data, Tesla credentials, raw provider responses, or undocumented fields; do not add them to diagnostics. ``` ## Prompt 4: pull sync, ETag, cursor, and history worker ```text Implement the canonical pull-sync worker for a BOT integration in [LANGUAGE/FRAMEWORK/DATABASE]. Use only the supplied OpenAPI and operator guide. Start with GET /capabilities, then GET /sync without updated_since for recovery or initial sync. For each page, apply upserts and tombstones idempotently in one durable transaction and store next_cursor only after the entire page commits. Send the opaque cursor back unchanged as updated_since; never parse or synthesize it. Persist ETag values and use If-None-Match, treating 304 as an unchanged poll. Paginate order/vehicle history independently and do not claim completeness while history_complete=false. Poll no more often than the approved quota; use 15 minutes by default. Respect the documented maximum 500 records/8 MiB response, four concurrent requests, 20/minute burst and 600/hour baseline, plus all effective values returned by /capabilities. Honor Retry-After on 429 and use bounded jittered backoff for retryable failures. Persist every documented optional allowlisted field that is useful to the integration, including order and stock-vehicle option_codes. Preserve each permitted history item in sequence order, including indexed changes such as option_codes[0], without treating an option code as a VIN/order identifier. Never fabricate a missing option code or collapse history_complete=false into a complete result. Give me the schema, transaction pseudocode, runnable worker code, crash/restart behavior, cursor-reset recovery, and tests for duplicate pages, concurrent runs, 304, partial history, out-of-order local jobs, tombstones, 410, 429, and 503. Store only the current allowlisted projection for resources explicitly shared with this integration. Never request, infer, scrape, log, store, return, or derive a VIN, real order number, BOT account identifier, contact/address/ payment/financing data, Tesla identifiers or credentials, raw provider responses, or undocumented fields. Do not use timestamps as a replacement for BOT's cursor, skip tombstones, scrape internal BOT/mobile interfaces, broaden scopes, or bypass sandbox/production separation and manual production approval. ``` ## Prompt 5: exact-order linking page and link-code redemption ```text Build the operator-side "My order" linking flow in [LANGUAGE/FRAMEWORK]. The user has already selected exact resources and consented inside BOT. On my site, accept one integration-bound ten-digit link code as a string so leading zeroes are preserved. Do not place it in a URL. Do not log, persist beyond the exchange, or send it to analytics. From the server that holds this integration's matching mTLS credential, POST it to /link-codes/redeem. On success, store only the random connection ID and integration-specific resource IDs returned by BOT. Never ask for a BOT login, account detail, VIN, or real order number and never attempt to match or infer an order from other data. Design accessible UI states for input, success, expiry/invalid code, throttling, temporary failure, and a privacy explanation. Codes expire after ten minutes, are single-use, and allow at most five failed attempts per code; server-side BOT limits also include ten attempts per source IP in 15 minutes and 60 per integration/hour. Treat non-redeemable responses as opaque and do not reveal whether a connection/resource exists. If the initial sync is not complete, do not consume, brute-force, inspect, or work around the code; show a neutral retry- later message. Include CSRF, abuse controls, telemetry redaction, and tests for leading zeroes, concurrent redemption, reuse, expiry, and 429 Retry-After. Place the supplied BOT credit and app link prominently beside the linked BOT order output. If the page mixes BOT and third-party data, label every BOT-derived record or entry at its point of display; a footer is not sufficient. Treat ads, AdSense, sponsorships, affiliate revenue, subscriptions, paid access, or any other direct/indirect monetization as commercial and require an individual written BOT agreement before enabling it. Do not confuse user consent, sandbox access, production approval, or a certificate with commercial permission. Use only documented BOT Operator API routes. Never scrape internal BOT/mobile interfaces, bypass mTLS or production approval, broaden consent/scopes, correlate IDs across integrations, or request/infer/store VIN, real order number, BOT account/contact/address/payment data, Tesla credentials, raw provider responses, or undocumented fields. ``` ## Prompt 6: revocation, tombstone deletion, and acknowledgement ```text Implement a fail-closed revocation processor for a BOT integration in [LANGUAGE/FRAMEWORK/DATABASE/OBJECT STORAGE]. Use tombstones from GET /sync as the authoritative signal that access has already ended. In the same durable workflow, make the resource unavailable, remove its current snapshot, full history, search/index/cache/analytics derivatives, queued rich payloads, and any other retained operator copy covered by policy. Track deletion work without retaining the deleted personal payload. Only after every deletion step succeeds, POST /revocations/{id}/ack with {"deletion_completed":true} and a stable unique Idempotency-Key. Make retries safe. Complete and acknowledge within seven days; surface an operational alert well before the day-five warning. Treat 410 on a detail endpoint as the same mandatory-deletion condition. Remember that a fresh initial sync can replay retained tombstones, so cursor loss must not lose the obligation. Provide a state machine, schema, worker code, retry/dead-letter policy, deletion inventory, audit evidence that contains no deleted payload, and tests for partial failure, duplicate tombstones, cursor reset, ACK timeout/retry, connection-wide revocation, and suspension after a missed deadline. Never delay access removal until ACK, acknowledge before deletion, restore data from a stale cache/backup, or include rich data in a revocation notification. Never request, infer, scrape, log, retain, return, or derive a VIN, real order number, BOT account identifier, contact/address/payment/financing data, Tesla identifiers or credentials, raw provider responses, or undocumented fields. Never use internal BOT/mobile interfaces or bypass consent, mTLS, scopes, or production gates. ``` ## Prompt 7: optional signed webhook receiver ```text Implement an optional BOT webhook receiver in [LANGUAGE/FRAMEWORK]. Pull sync must remain the canonical recovery source. Follow the supplied AsyncAPI contract and RFC 9421 HTTP Message Signatures. Accept only a public HTTPS endpoint that I register and verify in the BOT portal. Before parsing or acting on the JSON body, verify Content-Digest and the Ed25519 HTTP Message Signature, including the covered method/target/components required by the contract. Fetch BOT's versioned public key set from the documented same-portal JWKS URL, cache it only for its advertised lifetime, and reject an unknown keyid. Enforce timestamp freshness, store x-bot-event-id for replay protection, durably enqueue the exact verified event once, and return 2xx only after durable acceptance. Handle duplicates, delays, key rotation, temporary queue failure, and events arriving around a pull sync without assuming webhook order. Provide code, configuration, a verification test harness with valid and tampered messages, and an operations runbook. Revocation events are minimal deletion signals and must trigger the same deletion workflow as sync tombstones; never expect or require a rich revocation payload. Do not expose private/reserved callback targets, follow redirects during endpoint verification, trust unsigned headers/body, skip digest verification, fetch keys from an attacker-selected URL, or make webhooks the only recovery mechanism. Never request, infer, scrape, log, store, return, or derive a VIN, real order number, BOT account identifier, contact/address/payment/financing data, Tesla identifiers or credentials, raw provider responses, or undocumented fields. Do not bypass mTLS/scopes/consent or sandbox and manual production gates. ``` ## Prompt 8: privacy, isolation, contract, and quota test plan ```text Create and implement a security/privacy-focused test plan for my BOT integration backend in [LANGUAGE/TEST FRAMEWORK]. Derive behavior from the supplied OpenAPI, AsyncAPI, field catalogue, and consent/revocation guide. Use synthetic sandbox fixtures only. Include schema/contract tests; mTLS environment mismatch and revoked/expired certificate tests; at least ten synthetic integration tenants proving no cross- tenant connection, resource ID, cursor, statistics, certificate, webhook, or cache access; link-code expiry/single-use/leading-zero/concurrency/brute-force tests; initial/delta sync, opaque cursor, ETag/304, history_complete, pagination, idempotency, crash recovery, tombstone and 410 tests; immediate revocation plus full deletion/ACK tests; aggregate-only statistics with no individual records; webhook signature/digest/replay/duplicate tests if enabled; and error/log/ telemetry snapshots. Add leak canaries and assert that VIN, real order number, BOT account ID/contact/ address/payment/financing data, Tesla IDs/tokens/credentials, raw provider responses, GPS/presence-sensitive state, and undocumented fields never appear in API-derived persistence, responses, history, statistics, webhook payloads, logs, traces, metrics, exceptions, analytics, fixtures, or exports. Verify effective quotas from /capabilities, the baseline 600/hour, 20/minute burst, four concurrent, 500 records/8 MiB, statistics 120/hour/2 MiB, and correct Retry-After behavior; do not write a load test that intentionally attacks or evades BOT limits. Add tests or review assertions proving: current Integration Terms acceptance is required before integration creation and repeated for each new version; the standard licence rejects ads, Google AdSense, sponsorships, affiliate revenue, subscriptions, paid access, resale/data licensing, and all other monetization without an individual written BOT agreement; BOT credit/app link is conspicuous; and every BOT-derived record, entry, chart series, or result in mixed-source output is labelled at the output point instead of only in a footer. The plan must not scrape internal BOT/mobile interfaces, broaden scopes, disable TLS/mTLS, use real production user data, infer prohibited fields, or bypass manual production approval. List every untestable assumption as a production blocker instead of marking it passed. ``` ## Prompt 9: production-readiness review ```text Act as a strict production-readiness reviewer for an operator-owned BOT integration. Review the supplied implementation, BOT OpenAPI/AsyncAPI contracts, operator/field/consent guides, portal application profile, and sandbox evidence. Return: (1) blockers, (2) high/medium/low risks, (3) evidence matrix, (4) exact remediation tasks, and (5) a go/no-go recommendation. Do not treat missing evidence as passed. Require evidence for: immutable public name/slug and clear purpose; verified support contact and HTTPS website/privacy/terms/linking URLs; only necessary reviewed scopes; explicit acceptance of the current BOT Integration Terms and a re-acceptance mechanism for each new version; required conspicuous BOT credit and app link plus review URL; per-record/entry/series attribution at the output point for mixed-source displays; a non-commercial business model or an individual written BOT agreement covering all ads, AdSense, sponsorships, affiliate revenue, subscriptions, paid access, resale/data licensing, and other direct or indirect monetization; operator data retention/deletion policy; environment-separated secrets, database and mTLS clients; locally protected key/CSR and tested certificate rotation/revocation; successful synthetic sandbox contract, isolation, privacy, rate-limit, cursor/ ETag, history and revocation tests; 15-minute default pull with durable recovery; optional webhook signature/replay tests; monitoring that redacts payloads and credentials; a seven-day deletion/ACK runbook; legal/privacy approval; rollback and incident response; and explicit BOT manual production approval with a separate production client/certificate. Production must remain NO-GO while any required profile field/evidence is missing, review is pending/rejected/suspended, a sandbox credential is being used, mobile consent/data synchronization is unavailable, legal gates are open, the current terms version is unaccepted, commercial use lacks an individual written BOT agreement, attribution/provenance is incomplete, or tests reveal prohibited data. Never suggest a workaround for a gate, internal BOT/mobile scraping, broader scopes, or access to VIN, real order number, BOT account/contact/address/payment/financing data, Tesla identifiers/credentials, raw provider responses, or undocumented fields. The review cannot grant access; only BOT's manual approval and issued production credential can do so. ``` ## Authoritative inputs to attach to an AI session - `https://integration.boringordertracker.com/docs/openapi.yaml` - `https://integration.boringordertracker.com/docs/asyncapi.yaml` - `https://integration.boringordertracker.com/docs/guides/operator-guide` - `https://integration.boringordertracker.com/docs/guides/field-catalog` - `https://integration.boringordertracker.com/docs/guides/consent-and-revocation` - `https://integration.boringordertracker.com/docs/guides/mtls-certificates` - `https://integration.boringordertracker.com/docs/guides/versioning` - `https://integration.boringordertracker.com/terms` - `https://integration.boringordertracker.com/schemas/sync-response.json` - `https://integration.boringordertracker.com/schemas/order-response.json` - `https://integration.boringordertracker.com/schemas/vehicle-response.json` - `https://integration.boringordertracker.com/schemas/history-response.json` - `https://integration.boringordertracker.com/schemas/problem.json` - `https://integration.boringordertracker.com/schemas/revocation-ack-request.json` - `https://integration.boringordertracker.com/schemas/revocation-ack-response.json` Do not attach certificates, private keys, P12 passwords, one-time claim tokens, link codes, production response bodies, or user data to an AI session.