Jardine AI logo
Sign in

Key Endpoints

Jardine has a broad API surface, but most teams rely on a focused subset for daily operations and automation. The sections below focus on high-value endpoints in real support workflows, so you can choose routes by use case instead of by raw listing.

Organization and Settings Endpoints

If your workflow needs to read or update organization-level setup, these are foundational:

  • GET /api/organizations/me
  • PATCH /api/organizations/me
  • GET /api/organizations/me/settings
  • PATCH /api/organizations/me/settings

These are commonly used for setup status checks and org-level configuration updates. In onboarding logic, settings state is also used to determine readiness signals such as whether auto-respond behavior is enabled.

When automating against settings, separate read and write phases so unexpected updates are easier to detect.

Knowledge and Ingestion Endpoints

For content-driven quality work, the highest-value endpoints are:

  • GET /api/knowledge/collections
  • POST /api/knowledge/collections
  • PATCH /api/knowledge/collections/{id}
  • POST /api/knowledge/documents/upload
  • POST /api/knowledge/documents/text
  • POST /api/knowledge/documents/google-drive
  • POST /api/knowledge/documents/{id}/reingest
  • GET /api/knowledge/analysis

These cover collection lifecycle, ingestion paths, re-ingestion, and health monitoring. Teams usually use these endpoints when syncing policy updates or running content refresh jobs.

A common best practice is to pair ingestion operations with analysis checks, rather than assuming upload completion equals retrieval readiness.

Validation Endpoints for Quality Control

For controlled testing and regression prevention, these endpoints are critical:

  • GET /api/knowledge/validation/playground/conversations
  • POST /api/knowledge/validation/playground/conversations
  • PATCH /api/knowledge/validation/playground/conversations/{id}
  • GET /api/knowledge/validation/playground/conversations/{id}/messages
  • POST /api/knowledge/validation/playground/conversations/{id}/messages
  • POST /api/knowledge/validation/outcome/simulate
  • GET /api/knowledge/validation/suite
  • PUT /api/knowledge/validation/suite
  • POST /api/knowledge/validation/suite/run
  • GET /api/knowledge/validation/runs
  • GET /api/knowledge/validation/runs/{id}

These endpoints map directly to advanced validation features in the dashboard: chat testing, simulation, suites, and run history. For teams serious about release safety, this group is often more important than any single channel endpoint.

Conversation Endpoints for Operations

For production operations and ownership control:

  • GET /api/conversations
  • GET /api/conversations/{id}
  • POST /api/conversations/{id}/handover

These endpoints support queue views, detailed thread inspection, and explicit ownership handover between AI and humans.

If your ops workflow includes incident triage, this group is where most investigations begin.

Routing Endpoints for Policy

For manual routing control:

  • GET /api/routing/tags
  • POST /api/routing/tags
  • PATCH /api/routing/tags/{id}
  • GET /api/routing/destinations
  • POST /api/routing/destinations
  • PATCH /api/routing/destinations/{id}
  • GET /api/routing/rules
  • POST /api/routing/rules
  • PATCH /api/routing/rules/{id}

Use these when your team needs explicit policy automation beyond default routing behavior.

A practical warning: keep rule automation versioned and reviewable. Untracked policy scripts can create hard-to-debug changes in escalation behavior.

Connector Endpoints for Runtime Context

For account-aware support behavior:

  • GET /api/connectors
  • POST /api/connectors
  • PATCH /api/connectors/{id}
  • POST /api/connectors/{id}/validate
  • GET /api/connectors/{id}/schema-snapshot
  • POST /api/connectors/{id}/rotate-credentials
  • GET /api/connectors/{id}/templates
  • POST /api/connectors/{id}/templates
  • PATCH /api/connectors/{id}/templates/{template_id}
  • POST /api/connectors/{id}/templates/{template_id}/test

These endpoints support connector lifecycle, template governance, and runtime validation. They are usually operated by engineering-enabled support teams or platform owners.

Channel and Integration Endpoints

For email channel setup:

  • GET /api/channels/email/inbound-config
  • GET /api/channels/email/domains
  • POST /api/channels/email/domains
  • POST /api/channels/email/domains/{domain_id}/verify

For Intercom and Zendesk integration setup:

  • GET /api/integrations/intercom/status
  • GET /api/integrations/intercom/connect-url
  • POST /api/integrations/intercom/oauth/exchange
  • GET /api/integrations/zendesk/status
  • GET /api/integrations/zendesk/connect-url
  • POST /api/integrations/zendesk/oauth/exchange
  • POST /api/integrations/zendesk/webhook-secret

These endpoints are used heavily during channel onboarding and channel incident recovery.

Choosing Endpoints by Workflow

A practical way to pick endpoints is by operational question.

If the question is “why are answers weak?”, go knowledge + validation.

If the question is “why did this escalate?”, go conversations + routing + simulation.

If the question is “why can’t we answer account-specific requests?”, go connectors + template test.

If the question is “why are channel messages missing?”, go integration/channel setup + webhooks.

This workflow-first approach saves time and keeps API usage coherent.

For inbound channel contract details, continue with Webhooks.