Navigatr App Navigatr API
Official vendor OpenAPI document · agent-readyIdentity AuthDirectory ServicesapiKey1 EndpointsREST
For Agents
Look up a Navigatr user record by ID using a single authenticated GET request.
Use for: Get the Navigatr user detail for ID 12345, Look up a Navigatr user by ID, Retrieve a user's attributes from the Navigatr platform, Check whether a Navigatr user record exists for a given ID
Not supported: Does not handle user creation, authentication flows, or Navigatr application data beyond the user record - use for retrieving a Navigatr user detail by ID only.
The Navigatr API provides programmatic read access to user records inside the Navigatr platform. The current OpenAPI surface exposes a single GET endpoint that retrieves a user detail record by identifier, authenticated via the X-Access-Token header. It is intended for backend integrations that need to look up Navigatr user attributes from another system.
Install Jentic One Beta
Connect the Navigatr API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Navigatr 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.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fnavigatr.app%2Fnavigatr" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fnavigatr.app%2Fnavigatr" | sh
jentic register # connects your agent to your Jentic One instanceJentic 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 Navigatr API.
Retrieve a Navigatr user detail record by user ID via GET /user_detail/{id}
Authenticate Navigatr requests using the X-Access-Token header
Pull Navigatr user attributes into external CRM, analytics, or support systems
Verify that a Navigatr user ID exists before initiating downstream workflows
Surface Navigatr user records inside agent-driven support and onboarding flows
Use Cases
Patterns agents use Navigatr API for, with concrete tasks.
★ Cross-System User Lookup
Operations and support tooling outside the Navigatr platform often holds only the Navigatr user ID and needs the corresponding profile fields to render context for an agent or CSM. A single GET to /user_detail/{id} returns the user record so the calling system can hydrate its own view without screen-scraping. Wiring the lookup is straightforward because the surface contains only one operation.
Call GET /user_detail/12345 and return the JSON user record for display in the support agent console.
CRM Contact Enrichment
Sales and customer success tools often hold a Navigatr ID against each contact and benefit from refreshing Navigatr profile fields onto the CRM record. Iterating over contacts and calling /user_detail/{id} keeps the CRM record aligned with Navigatr without manual exports. The workflow runs in batches because the API is read-only and per-record.
For each CRM contact carrying a navigatr_id, call /user_detail/{id} and update the CRM record with the latest Navigatr profile fields.
Validation Before Workflow Triggers
Automation tools that reference Navigatr user IDs in upstream events (webhooks, message queues) need a quick existence check before kicking off downstream work. A guarded GET /user_detail/{id} returns the record on success and an error on a missing or revoked user, allowing the workflow to short-circuit safely. This avoids surfacing stale or invalid IDs to downstream systems.
Before processing a Navigatr-triggered webhook, call /user_detail/{id} and only continue when the response status is 200.
Agent-Driven Navigatr Profile Lookup via Jentic
Agent assistants that triage support tickets or onboard users need a one-shot Navigatr profile read without managing the X-Access-Token directly. Through Jentic the agent searches by intent, loads the schema for /user_detail/{id}, and executes it with the user ID, while Jentic injects the access token from the vault. The agent never holds the raw token.
Search Jentic for 'look up a Navigatr user by ID', load the schema for /user_detail/{id}, and execute it with the user ID extracted from the support ticket.
Key Endpoints
1 endpoints — the navigatr api provides programmatic read access to user records inside the navigatr platform.
METHOD
PATH
DESCRIPTION
GET
/user_detail/{id}
Retrieve a Navigatr user detail record by ID
GET
/user_detail/{id}
Retrieve a Navigatr user detail record by ID
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring Navigatr by hand means learning its X-Access-Token header auth on the api.navigatr.app host and handling errors on each user lookup yourself. Through Jentic you install once, import the Navigatr API from the API Directory, store the token once, and your agent calls it.
Permission scoping
Navigatr puts the user id in the URL path (/user_detail/{id}), and the only operation is a read, so a rule can pin your agent to that user-detail lookup. It retrieves a user record and does nothing that changes state, since no write operation is in the allowed set.
Credential isolation
Your Navigatr X-Access-Token is stored once, encrypted, by your own Jentic One instance and injected into the request header at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'look up a Navigatr user by ID', and Jentic returns the single Navigatr operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Navigatr API through Jentic.
What authentication does the Navigatr API use?
The Navigatr API authenticates each request with an X-Access-Token header carrying the API key. Jentic stores the token in its vault and injects it at execution time so the agent never sees the raw secret.
Can I list all Navigatr users with this API?
No. The current OpenAPI surface exposes only a single read operation, GET /user_detail/{id}, which returns one user at a time keyed by ID. Iterating over a known set of IDs is the supported way to read multiple users.
What are the rate limits for the Navigatr API?
The OpenAPI spec does not publish rate limits. Throttling is governed at the account level - confirm your plan limits with Navigatr support before running a high-volume enrichment loop against /user_detail/{id}.
How do I look up a Navigatr user through Jentic?
Run pip install jentic, search for 'look up a Navigatr user by ID', load the schema for /user_detail/{id}, and execute it with the user ID. Jentic adds the X-Access-Token header from your vault entry. Run it through Jentic One, the self-hosted execution layer.
Does this API let me create or update Navigatr users?
No. The current surface is read-only. Creating, updating, or deleting Navigatr users must be performed through the Navigatr application, which is not covered by this OpenAPI spec.
Can I limit what my agent is allowed to do with the Navigatr API?
Yes. Jentic One is self-hosted, so your own rules decide which operations and credentials the agent may use. Because the Navigatr API exposes only a single read operation, GET /user_detail/{id}, and the user ID lives in the URL path, you can pin the agent to that user-detail lookup and nothing else. Since no write operation is in the allowed set, the agent can retrieve a user record but cannot create, update, or delete anything.
GET STARTED