funeralOne f1Connect API

Name: funeralOne f1Connect API
Brand: funeralOne f1Connect API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentCRMContact Managementbasic3 EndpointsREST

For Agents

Create funeral case records in the funeralOne f1Connect platform and retrieve them by account or case external ID for syncing case management systems with tribute websites.

Install Jentic One Beta

Connect the funeralOne f1Connect API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the funeralOne f1Connect 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://jentic.com/install.sh?src=apis&api=%2Fapis%2Fapi.funeralone.com%2Ffuneralone" | sh

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%2Fapi.funeralone.com%2Ffuneralone" | 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 funeralOne f1Connect API.

Create a new funeral case with deceased details, events, and serving locations

List all cases under a funeral home account by external account ID

Retrieve a single case by external account and external case identifier

GET STARTED

Start building with funeralOne f1Connect API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use funeralOne f1Connect API for, with concrete tasks.

★ Funeral Home Case Sync

Sync newly created case records from a funeral home's primary management system into f1Connect so the tribute website, obituary, and family-facing pages are populated automatically. POST /cases creates the record with deceased, event, and serving-location details, and the GET endpoints let the source system reconcile what is already in f1Connect by external ID.

POST /cases with the AccountExternalId, CaseExternalId, deceased details, and event list to create the case in f1Connect

Tribute Website Population

Power a funeral home's tribute website by creating cases through the API as soon as arrangements are entered into the back-office system. The case payload carries the events (visitation, service, committal) and serving locations needed to render the public memorial page without manual entry by the funeral director.

POST /cases for a newly arranged service, then verify creation with GET /cases/AccountExternalId/{AccountExternalId}/CaseExternalId/{CaseExternalId}

Reconciliation Audits

Audit which cases have been pushed into f1Connect for a given funeral home over a period. GET /cases/AccountExternalId/{AccountExternalId} returns all cases for the account, which can be diffed against the source system to catch missed syncs and re-push them. Useful before annual reviews or when changing back-office systems.

GET /cases/AccountExternalId/{AccountExternalId} to enumerate all cases on f1Connect, then diff against the source system list and POST /cases for any missing

AI Agent Case Creation via Jentic

An AI agent that watches the funeral home's case management system can call f1Connect through Jentic to push new cases as they are arranged. Jentic isolates the basic auth credentials and exposes the three operations as discoverable tools, so the agent only needs the case payload.

Search Jentic for 'create a funeral case in f1connect', load the POST /cases schema, and execute with AccountExternalId and the case payload

Key Endpoints

3 endpoints — jentic publishes the only available openapi specification for funeralone f1connect api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

POST

/cases

Create a funeral case with deceased details, events, and serving locations

GET

/cases/AccountExternalId/{AccountExternalId}

List all cases for a funeral home account

GET

/cases/AccountExternalId/{AccountExternalId}/CaseExternalId/{CaseExternalId}

Retrieve a specific case by external IDs

POST

/cases

Create a funeral case with deceased details, events, and serving locations

GET

/cases/AccountExternalId/{AccountExternalId}

List all cases for a funeral home account

GET

/cases/AccountExternalId/{AccountExternalId}/CaseExternalId/{CaseExternalId}

Retrieve a specific case by external IDs

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring the funeralOne f1Connect API by hand means setting up its HTTP basic auth and coding your own calls to sync case records into f1Connect. Through Jentic you install once, import the funeralOne f1Connect API from the API Directory, store the credentials once, and your agent calls it.

Permission scoping

funeralOne puts the account and case external ids in the URL path (/cases/AccountExternalId/{AccountExternalId}/CaseExternalId/{CaseExternalId}), so a rule can pin your agent to reading one account or case. You choose the operations it may call, so creating a case is not included unless you add it.

Credential isolation

Your funeralOne basic auth credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'sync a case record' or 'look up a case by external id', and Jentic returns the matching funeralOne operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using funeralOne f1Connect API through Jentic.

Why is there no official OpenAPI spec for funeralOne f1Connect API?

funeralOne does not publish an OpenAPI specification publicly. Jentic generates and maintains this spec so that AI agents and developers can call funeralOne f1Connect API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

What authentication does the funeralOne f1Connect API use?

f1Connect uses HTTP Basic authentication with credentials issued by funeralOne. Through Jentic, the credentials are stored in the encrypted vault and the Authorization header is composed at execution time so they never enter the agent's context.

Can I list all cases for a single funeral home account?

Yes. GET /cases/AccountExternalId/{AccountExternalId} returns every case associated with that account's external ID. The response is keyed by CaseExternalId so the source system can reconcile what is already on f1Connect.

How do I create a case with multiple events and serving locations?

POST /cases accepts events and serving locations as nested arrays in the case payload, alongside deceased details. Submit them in a single request rather than chained calls - there is no separate endpoint for adding events to an existing case.

How do I push a new case to f1Connect through Jentic?

Run pip install jentic, then search 'create a funeral case in f1connect'. Jentic returns the POST /cases operation with its input schema. Execute with the AccountExternalId, CaseExternalId, and case payload; Jentic handles the basic auth header.

What identifies a case uniquely in this API?

The combination of AccountExternalId (the funeral home) and CaseExternalId (the case in the source system). Both are provided by the integrating system on POST /cases and reused on the GET endpoints, so f1Connect mirrors the source system's identifiers.

Can I limit what my agent is allowed to do with the funeralOne f1Connect API?

Yes. Because you run Jentic One yourself, your own rules decide which of the three f1Connect operations the agent may call and which credentials it may use, so you can allow only the read endpoints (GET /cases/AccountExternalId/{AccountExternalId} and the single-case GET) while withholding case creation via POST /cases. Since funeralOne puts the account and case identifiers in the URL path, a rule can also pin the agent to reading a single account or a single case. The basic auth credentials stay with your instance and are attached at execution time, so a scoped agent never gains broader access than you grant.