Integration selection guide
Choose integrations according to the result you need, the system that owns each record, and whether GEO only reads evidence or is allowed to perform an approved external mutation. Do not connect every available system by default.
Quick decision table
| Need | Recommended surface | Direction |
|---|---|---|
| Observe answers from public AI systems | Workspace provider | GEO calls provider |
| Evaluate a private assistant or agent | Custom-agent provider or AI component | GEO calls approved endpoint |
| Represent MCP, RAG or workflow dependencies | AI component registry | Configuration and evaluation |
| Send internal analytics or search data to GEO | Workspace data connection or API | External system to GEO |
| Track AI referrals and conversions | Browser/Next.js/GTM/WordPress SDK or Events API v2 | Website/server to GEO |
| Publish approved website content | CMS or generic REST connection | GEO to destination |
| Publish machine-readable artifacts | Repository, object storage, CMS or webhook | GEO to destination |
| Create work for human teams | Jira, Linear, GitHub Issues or webhook adapter | GEO to work system |
| Notify teams | Slack, Teams, e-mail or webhook delivery | GEO to destination |
| Query metrics and reports programmatically | REST API or TypeScript SDK | Client to GEO |
| Let an approved AI client query GEO | GEO MCP | MCP client to GEO |
| Export to a warehouse | Scheduled export or warehouse connection | GEO to warehouse |
Provider integration
Use a provider when GEO must execute prompts and store observed answers. Configure providers per workspace so credentials, cost limits and evidence policy cannot leak across tenants.
Choose:
openai_compatiblefor OpenAI-compatible chat APIs and supported compatible endpoints.anthropic_compatiblefor Claude Messages-compatible APIs.perplexity_compatiblefor search-grounded answers and citation evidence.custom_agentfor a customer-owned agent contract.
Use multiple providers when the business question is cross-engine visibility. Keep results separate by provider/model; aggregate only through a metric definition that declares its denominator.
Tracking integration
Use browser tracking for page and referral context, server-side Events API for trusted conversion events, or both with a shared event ID for deduplication.
| Environment | Recommended option |
|---|---|
| Static or server-rendered website | Browser script /geo.js |
| Next.js application | @thyris/geo-tracking/next |
| Tag-manager-owned deployment | Google Tag Manager template |
| WordPress | GEO tracking plugin |
| Backend conversion source | TypeScript server client or Events API v2 |
| Restricted browser environment | Server-side event forwarding |
Publishing integration
Use a channel connection only when GEO is expected to create a preview or perform an approved change. If the team only needs recommendations, keep the workflow at draft/action export.
| Destination | Use when | Important controls |
|---|---|---|
| WordPress, Contentful, Sanity, Strapi, Webflow, Shopify or AEM | Structured website/page content is managed in a supported CMS | Content type mapping, preview, scoped token, rollback |
| Generic REST CMS | The destination has a documented HTTPS API | Allowlists, schema mapping, idempotency, read-after-write |
| GitHub/GitLab | Content, llms.txt, JSON-LD or configuration is reviewed as code | Branch, pull/merge request, reviewer and protected branch policy |
| Object storage | Machine artifacts or feeds are delivered as files | Bucket/path scope, checksum and cache invalidation |
| Social or ads platform | Approved external API and OAuth scopes exist | Platform review, preview, spend/risk policy, rate limits |
| Generic webhook | A customer adapter owns the final mutation | Signed payload, idempotency and result callback |
Analytics and warehouse integration
Connect analytics when GEO needs downstream outcomes or an existing source of traffic truth. Define ownership: GEO tracking can be primary for AI referral analysis while GA4/Adobe/Matomo remains the broader analytics source.
Avoid double counting by documenting event IDs, timezone, currency, attribution window and bot filtering on both sides.
Work-management and notification integration
Recommendations may stay in GEO Action Center or be synchronized to an external work system. Select one system as the task status owner.
Use notifications for awareness, not approval impersonation. An approval performed in Slack or Teams is valid only when the adapter verifies the actor and records an auditable approval event.
REST API, SDK, or MCP
| Surface | Choose when | Authentication |
|---|---|---|
| REST API | A backend needs explicit HTTP contracts, exports or mutations | Workspace-scoped platform API key |
| TypeScript SDK | A TypeScript backend wants typed helpers over the REST contract | Same platform API key, server-side only |
| GEO MCP | An approved AI client needs bounded read or approval-request tools | Scoped platform API key and MCP tool permissions |
| Tracking Events API | A website/backend sends behavioral events | Dedicated tracking-site token |
Never use a platform API key in browser tracking, and never treat a tracking token as a dashboard/API credential.
Common combination patterns
Baseline measurement only
Use a provider, projects/targets, prompts and scheduled monitoring. No channel write access is needed.
Measure and publish
Use providers plus a CMS/repository connection and approval workflow. Add tracking before publication if impact measurement is required.
Enterprise data program
Use provider monitoring, server-side events, warehouse export and work-management synchronization. Keep raw evidence retention and access policy explicit.
Custom-agent evaluation
Register the agent, model, MCP tools, RAG sources and router/workflow dependencies. Observe real executions separately from synthetic simulation.
Selection questions
- What business decision should this integration support?
- Which system is authoritative for the resource or outcome?
- Is GEO reading evidence, writing a draft, or mutating an external system?
- Which workspace owns the credential and data?
- Are staging and production credentials separated?
- What scopes, allowlists and rate limits apply?
- How are retries, duplicate requests and out-of-order callbacks handled?
- What proves that a publication/action succeeded?
- What is the rollback and reconciliation path?
- Which data is retained, exported or deleted, and for how long?
Production acceptance
Do not mark an integration production-ready until it passes:
- Authentication and least-privilege scope checks
- Tenant/workspace isolation checks
- Invalid signature/token and expired credential tests
- Idempotency, duplicate and replay tests
- Rate-limit and downstream outage behavior
- Audit, redaction and secret-leak review
- Preview, approval, verification and rollback where writes exist
- Monitoring and owner/runbook assignment