Heyjodie Jodie API

Name: Jodie API
Brand: Jodie API
Availability: InStock

✓ Official Vendor SpecCommunicationsVoice Telephonybearer2 EndpointsREST

For Agents

Read Jodie account information and list AI-handled call records via Bearer-token authentication for the Jodie voice-agent platform.

Install Jentic One Beta

Connect the Jodie API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Jodie API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Jodie API.

Read the authenticated user's Jodie account information via GET /api/user

List call records handled by Jodie's AI voice assistant through GET /api/calls

Build a CRM-style call-history view by paginating GET /api/calls and joining with internal contact records

GET STARTED

Start building with Jodie API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Jodie API for, with concrete tasks.

★ AI Call History Dashboard

Operations teams call GET /api/calls on a schedule to populate an internal dashboard of calls Jodie has handled, including timestamps and any structured outcomes Jodie surfaces. This gives leaders visibility into AI call coverage without logging into the Jodie console for each shift.

Call GET /api/calls with a time-range filter, group results by hour, and post the totals to an internal dashboard.

CRM Sync for AI-Handled Calls

Sales platforms poll GET /api/calls and write each new record into a CRM contact's activity timeline so reps know when Jodie has spoken to a lead. This ensures AI-handled calls are visible alongside human calls in the same pipeline view rather than living in a separate silo.

Poll GET /api/calls every 5 minutes, then for each new call id, post the call summary to the matching CRM contact's activity feed.

Account Health Check

Account managers verify that their Jodie account is provisioned correctly by calling GET /api/user during onboarding or post-incident. The response confirms the user identity and any account-level metadata, which helps an agent diagnose whether a missing call is an auth issue or a routing problem.

Call GET /api/user and assert that the returned account status is active before triggering downstream calls.

AI Agent Call Coordination

Through Jentic, an AI agent can call 'list my recent voice agent calls' and turn the result into a daily standup summary, or check user-account state before delegating work to Jodie. Jentic's vault holds the Bearer token so the agent never sees the credential while still pulling Jodie's call data.

Search Jentic for 'list ai-handled calls', execute GET /api/calls for the last 24 hours, and produce a one-paragraph summary of call volume.

Key Endpoints

2 endpoints — the jodie api exposes account and call-history operations for jodie, an ai-powered calling assistant that handles inbound and outbound voice conversations.

METHOD

PATH

DESCRIPTION

GET

/api/user

Get account information for the authenticated user

GET

/api/calls

List calls handled by Jodie's AI voice agent

GET

/api/user

Get account information for the authenticated user

GET

/api/calls

List calls handled by Jodie's AI voice agent

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Jodie Bearer tokens are stored encrypted in the Jentic vault. Agents call Jodie via Jentic and the Authorization header is injected at execution time, so the raw token never enters the agent's context.

Intent-based discovery

Agents search by intent (e.g., 'list ai-handled calls') and Jentic returns the matching Jodie operation with its input schema, so the agent calls the right endpoint without scanning the spec.

Time to first call

Direct Jodie integration: half a day for auth and pagination handling. Through Jentic: under 30 minutes — search, load schema, execute.

FAQs

Specific to using Jodie API through Jentic.

What authentication does the Jodie API use?

Jodie uses Bearer token authentication. Generate the token from the Jodie dashboard and pass it in the Authorization: Bearer <token> header. Through Jentic, the token is stored in the encrypted vault and injected at execution time.

Can I list calls Jodie handled with the API?

Yes. GET /api/calls returns the call records that Jodie's AI voice agent processed for the authenticated account. Pair it with a polling loop or Jodie's webhooks (documented in the Jodie developer docs) to surface new calls in near real time.

How do I retrieve Jodie account information through Jentic?

Run pip install jentic, search for 'get my account information', and execute against GET /api/user. Jentic resolves the Bearer token from the vault and returns the JSON response.

Does the Jodie API support webhooks?

Yes — webhooks are documented in the Jodie developer docs even though the spec only enumerates two REST endpoints. Configure the webhook URL in the Jodie dashboard to receive call events instead of polling /api/calls.

What rate limits apply to the Jodie API?

The current spec does not publish explicit rate limits. Implement standard backoff on HTTP 429 responses and prefer webhook-driven event flows over high-frequency polling of /api/calls.