BILL Authentication API

Name: BILL Authentication API API
Brand: BILL Authentication API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentIdentity AuthAuthenticationapiKey6 EndpointsREST

For Agents

Connect the BILL Authentication API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the BILL Authentication 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.

Install Jentic One Beta (Self-Hosted)

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

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 BILL Authentication API API.

Authenticate with developer key, org ID, username, and password via /Login.json to obtain a session ID

Trigger an MFA challenge for the current session through /MFAChallenge.json

Submit an MFA token to complete authentication via /MFAAuthenticate.json

Check MFA status with /MFAStatus.json before issuing privileged calls

GET STARTED

Start building with BILL Authentication API API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for BILL Authentication API, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for BILL Authentication API, keeping it validated and agent-ready. The Authentication API is the entry point to BILL's v2 platform — callers exchange a developer key, organization ID, username, and password for a session ID via /Login.json, then carry that session ID on every subsequent call to the Approvals, Customer Management, Vendor, and other BILL APIs. The surface also covers MFA challenge, MFA authenticate, MFA status, session inspection, and logout. It is small but mandatory.

Use Cases

Patterns agents use BILL Authentication API API for, with concrete tasks.

★ Session Bootstrap for BILL Integrations

Every BILL v2 integration starts with a successful /Login.json call that returns a session ID. The session ID is then attached to every Approvals, AR, AP, and Vendor call until /Logout.json invalidates it. Integrations typically wrap login behind a reauth helper that detects expired sessions and re-issues credentials before retrying the failed downstream call.

Call POST /Login.json with devKey, orgId, userName, and password, capture the sessionId from the response, and use it for subsequent BILL calls

MFA Step-Up for Sensitive Operations

BILL accounts with MFA enabled must complete the challenge before privileged actions like Approve.json or payment runs are allowed. /MFAChallenge.json triggers delivery of the MFA token, /MFAAuthenticate.json verifies it, and /MFAStatus.json confirms the session is now MFA-authenticated. Integrations gate sensitive workflows behind a successful /MFAStatus.json check.

Call /MFAChallenge.json, prompt the user for the token, call /MFAAuthenticate.json, and verify with /MFAStatus.json before running an approval

Session Inspection and Cleanup

Long-running BILL integrations track active sessions for audit and clean shutdown. /GetSessionInfo.json returns the user, organization, and session metadata for diagnostics; /Logout.json terminates the session cleanly when a job ends. Both prevent dangling sessions from accumulating on the BILL side and keep audit logs tight.

Call /GetSessionInfo.json to log session metadata, then /Logout.json at job end

Agent-Driven BILL Login via Jentic

An AI agent acting on a BILL workflow first searches Jentic for a login intent, loads the BILL /Login.json operation, and executes it with the user's credential bundle from the vault. The returned session ID stays inside Jentic's runtime and is automatically attached to subsequent BILL calls, so the agent itself never sees the devKey, password, or session ID. This makes downstream Approvals or Customer-Management actions safe to chain.

Search Jentic for 'log in to BILL', load /Login.json, execute with the vault credentials, and proceed with downstream BILL operations using the returned sessionId

Key Endpoints

6 endpoints — jentic publishes the only available openapi specification for bill authentication api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

POST

/Login.json

Authenticate and obtain a session ID

POST

/Logout.json

Invalidate the active session

POST

/MFAChallenge.json

Trigger an MFA challenge

POST

/MFAAuthenticate.json

Submit an MFA token to complete authentication

POST

/MFAStatus.json

Check whether MFA has been completed

POST

/GetSessionInfo.json

Inspect the active session

POST

/Login.json

Authenticate and obtain a session ID

POST

/Logout.json

Invalidate the active session

POST

/MFAChallenge.json

Trigger an MFA challenge

POST

/MFAAuthenticate.json

Submit an MFA token to complete authentication

POST

/MFAStatus.json

Check whether MFA has been completed

Why though Jentic?

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

Credential isolation

BILL developer keys, organization IDs, and user passwords are stored encrypted in the Jentic vault. Agents call /Login.json by intent and Jentic supplies the credentials at execution time, retaining the returned session ID inside its runtime so neither the credentials nor the session ID ever enter the agent's context.

Intent-based discovery

Agents search by intent (e.g., 'log in to BILL', 'complete MFA') and Jentic returns the matching Authentication operation with its body schema typed, so the agent's prompt only needs to describe the action.

Time to first call

Direct BILL Authentication integration: 1-2 days handling session lifecycle, MFA branching, and reauth-on-401 logic. Through Jentic: under 30 minutes — search, load schema, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

BILL Approvals API

AP approval workflow that requires the session ID from this Authentication API

Always pair Authentication with Approvals — the session ID issued here is required on every Approvals call

Complementary

BILL Customer Management API

AR customer records that also depend on a BILL session

Pair when an integration manages AR customer data — the same session works for both APIs

Complementary

BILL Connect Events API

Webhook subscriptions for BILL platform events

Pair when downstream systems should be pushed events about BILL changes after the session is established

FAQs

Specific to using BILL Authentication API API through Jentic.

Why is there no official OpenAPI spec for BILL Authentication API?

BILL documents its v2 API in narrative form on developer.bill.com but does not publish the underlying OpenAPI document. Jentic generates and maintains a structured OpenAPI specification so AI agents and developers can call BILL Authentication API via tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the BILL Authentication API itself require?

The /Login.json endpoint accepts a developer key, organization ID, user name, and password as form-encoded fields. It returns a session ID that all other BILL v2 endpoints require. Through Jentic, the developer key, username, and password are stored encrypted in the vault and never enter the agent's context.

How do I handle BILL accounts with MFA enabled?

After /Login.json succeeds, call /MFAChallenge.json to trigger token delivery, /MFAAuthenticate.json to submit the user's token, then /MFAStatus.json to confirm the session is fully authenticated. Privileged operations (Approve, payment execution) require MFA to be complete on the session.

How long is a BILL session ID valid for?

BILL platform sessions expire after a period of inactivity defined by the org's security configuration — for unattended integrations the safest pattern is to catch the auth-error response on a downstream call and re-run /Login.json before retrying. /GetSessionInfo.json reveals current session details for diagnostics.

How do I log in to BILL through Jentic?

Run `pip install jentic`, then `await client.search('log in to BILL')`, `await client.load(...)` for /Login.json, and `await client.execute(...)`. Jentic uses the credentials in the vault and retains the returned sessionId for subsequent BILL operation calls within the same execution context.

Should I call /Logout.json at the end of a job?

Yes for short-lived scripts and integrations — /Logout.json releases the session on the BILL side, preventing dangling sessions and keeping audit logs clean. Long-running services typically reuse a session with reauth-on-401 logic instead of logging out and back in for each call.