On this page and tools
Engagements
Engagement types and stages
An engagement type is a named kind of client work in a Space, such as grooming, tutoring or repairs, with its own ordered stages. Managers set them up on the Engagements page, and an AI agent with its own key can read and manage them through the API.
AvailableHow a type works
- The status stays the machine state. Every engagement keeps one of the existing statuses, so payments, emails and the portal behave as before.
- A stage is a labelled step inside a status. Each stage names the status it sits in (
status_bucket). Moving to a stage may move the status along an allowed forward step, never backwards. A move the status cannot make is refused with409. - Stages must be reachable. Consecutive stages in different buckets must be one allowed step apart:
submittedtoin_revieworawaiting_payment,in_reviewtofiling, thenfiling,filed,issued,closedone at a time. A list that skips a step is refused withstage_unreachableand the allowed next buckets. - Stages follow the status order. A type has 1 to 12 stages, and their buckets may not go backwards through draft, submitted, awaiting_payment, in_review, filing, filed, issued, closed.
- Clients see only some stages. A stage with
client_visible: falseis shown to staff only. The portal returnstypeandstagewith each engagement ({key, label}or null). - Default items are priced lines in whole cents, checked by the same rules as an engagement's own charges.
Give an agent access
- Create an agent key. It starts in test mode.
- The agent asks for
read:engagement-typesandwrite:engagement-typeswithPOST /dash/api/v1/agent/access-requestsand areason. - The key owner, a manager or admin of the Space, approves each on the key page. If they stop being a manager or admin, the key switches off.
- To write for real, the owner moves the key to live. In test mode every write is a dry run.
The calls
All calls are under /dash/api/v1 and only see the key's own Space. A type from another Space answers 404.
| Call | What it does |
|---|---|
GET /engagement-types, GET /engagement-types/{key} | Read. The id of a type is its key. |
POST /engagement-types | Create. Body: key, label, stages, and optionally kind (service or formation), form_id (a frm_ id), booking_type_id, default_items, site (the key or id of one of the Space's sites, so the type shows only on that site's portal; leave it out for the whole Space). Honours Idempotency-Key. |
PATCH /engagement-types/{key} | Change label, kind, form_id, booking_type_id, site, stages, default_items or is_active. The key never changes. A stage that an engagement sits in cannot be removed. |
DELETE /engagement-types/{key} | Delete a type no engagement uses. Otherwise set is_active to false. |
Create a typebash
curl -X POST -H "Authorization: Bearer $BYNEFIT_API_KEY" -H "Content-Type: application/json" \
-H "Idempotency-Key: grooming-type-1" \
-d '{"key": "grooming", "label": "Grooming", "stages": [
{"key": "requested", "label": "Requested", "status_bucket": "submitted"},
{"key": "booked", "label": "Booked", "status_bucket": "in_review"},
{"key": "groomed", "label": "Groomed", "status_bucket": "filing"},
{"key": "ready", "label": "Ready for pickup", "status_bucket": "filed"},
{"key": "picked-up", "label": "Picked up", "status_bucket": "issued"}
], "default_items": [{"label": "Full groom", "kind": "service", "qty": 1, "unit_cents": 7500}]}' \
https://bynefit.com/dash/api/v1/engagement-types
Limits and safety
- Key. 2 to 40 characters of a-z, 0-9,
_or-, unique in the Space. - Size. At most 50 types in a Space. Labels are 1 to 80 characters, stage labels 1 to 60.
- No client data. These permissions never read or change an engagement or a client.
- Ceiling. Live writes share the key's daily write budget with forms. A key in test mode, or a call with
"dry_run": true, is checked and writes nothing. - Log. Every live change is recorded in the Space activity log with the key, the type key and the action, never the content.
Errors
| Status | error | What to do |
|---|---|---|
| 403 | insufficient_scope | Request the permission and have the owner approve it. |
| 404 | not_found | The type is not in this Space. |
| 409 | key_taken, type_in_use, stage_in_use, type_limit_reached | Pick another key, deactivate instead of deleting, move the engagements first, or delete a type. |
| 422 | invalid_key, invalid_label, invalid_stages, invalid_stage_key, invalid_stage_label, invalid_status_bucket, stage_order, stage_unreachable, duplicate_stage_key, invalid_default_items, form_not_found | Fix the field named in message. |
| 429 | agent_write_budget_spent, agent_limits_unavailable | Wait for midnight, server time, or try again in a minute. |
What exists and what does not
- Read community resourcesList and filter community resources with a developer key. JSON, cursor paging.Available
- Submit a resource for reviewPropose a new entry. A moderator reviews it before it goes live.Available
- Partner eventsPartners send their own product events from a page, a server or an app, and read the totals back. Bynefit turns it on per partner.By approval
- Hosted sites runtimeEvents, resources, media, forms and page views for a hosted site, with no key.Available
- Read and edit hosted site filesAn agent key lists a Space's sites and reads, replaces and deletes their files, with versions, secret scanning and a daily write ceiling. The key owner approves the permission.Available
- Create and manage formsAn agent key creates forms for a Space, changes their settings and fields, pauses them and deletes unanswered ones, with a daily write ceiling and a test mode. Registration forms and submissions stay out of reach. The key owner approves the permission.Available
- Engagement types and stagesA Space defines its own kinds of client work with ordered stages inside the existing statuses. Managers edit them on the Engagements page, and an agent key reads and manages them with a daily write budget and a test mode. The key owner approves the permissions.Available
- Client portal APIA signed-in client reads their own engagements, documents and messages; a practice manager runs the pipeline.Available
- Engagements through an API key or a webhookRead engagements from your own server, or hear about a change, without a person signed in.Planned
- Every docs page as MarkdownAdd ?format=md to any docs page, or send Accept: text/markdown.Available
- llms.txt indexA short index of the docs for tools that read llms.txt, at /docs?format=llms.Available
- OpenAPI specAn OpenAPI 3.1 description of the v1 API, with the error envelope and security schemes, at /docs?format=openapi.Available
- Agent skill and integration briefAn installable SKILL.md and a paste-in brief, generated from the same code as the spec.Available
- Agent keysA key made for an AI agent: read-only to start, short-lived, test mode first, every call logged, and the owner approves anything more.Available
- Request id and docs link on every errorEvery error body carries an id to quote to support and a link to the page that explains it.Planned
- Test keys and a sandboxKeys that only touch sample data, ready at once with no review, so a first attempt cannot break anything.Available
- Idempotency-Key on writesRetry a v1 write without doing it twice: the first answer is replayed for 24 hours, per key.Available
- Status pageLive state, 90-day uptime and incident history for the API, sign-in, webhook delivery, the widget, hosted sites and email. Atom and JSON feeds.Available
- Docs MCP serverRead-only search of these docs from an AI tool.Available