canonical: https://jentic.com/apis/navigatr.app/navigatr

# Navigatr App Navigatr API

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.

## For AI agents

Look up a Navigatr user record by ID using a single authenticated GET request.

## Scope

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.

## Capabilities

- 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

### 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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

| Method | Path | Description |
| --- | --- | --- |
| GET | `/user_detail/{id}` | Retrieve a Navigatr user detail record by ID |

## Key resources

- **User Detail** — Read-only retrieval of a Navigatr user profile by ID

## Why Jentic

- **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 handling:** 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.
- **Discovery method:** 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

- **Okta API** — Enterprise identity platform with full user CRUD and SSO for cases needing more than read-by-ID.
- **Auth0 Management API** — Identity and user management API with broader profile management surface.
- **HubSpot Contacts API** — CRM contact store commonly enriched with attributes pulled from Navigatr user records.

## FAQ

### 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.