Changelog

This page records every change to the developer platform: the REST API, webhooks, OAuth and the developer tools. The newest entry is at the top.

How changes are announcedCopy Anchor Link

• Every change is listed here, with its date and what you need to do, if anything.
• During the preview, names and fields may still change before general availability. Changes that could break an integration are marked Breaking and explained, with the reason and how to update your code.
• After general availability, /v1 only changes in backwards-compatible ways: new endpoints, new optional fields, new enum values and new event types can appear at any time, so ignore anything you don't recognise. Anything that would break existing code waits for a new major version, which runs alongside the old one for at least 12 months. See versioning.
• Deprecations are announced here before anything is removed, with the date it stops working.

Each entry uses these labels:

2026-10-05 — person.reactivatedCopy Anchor Link

Added

• person.reactivated. Sent when a deactivated person is reactivated in the console, with the same Person object as person.deactivated. There are now 30 event types. Endpoints subscribed to * receive it; others can add it.

2026-10-02 — Form builder and protected answersCopy Anchor Link

Admins now build forms in Console → Settings → Forms, so the schemas behind custom_fields change when they publish.

Added

• Screen order. Form schemas (GET /forms, and public_form on visit types and booking types) list their properties in screen order in x-agoo-order. JSON objects don't keep key order, so use it rather than the order of properties.
• Field annotations. Properties carry x-agoo-type (the builder's field type), and where they apply x-agoo-labels (choice labels by value), x-agoo-unit, x-agoo-consent-text, x-agoo-show-if (asked only after an earlier answer) and x-agoo-sites (asked only at those sites). Conditional requirements are allOf if/then rules.
• Yes or no questions are boolean properties, like consent. A Person question is a string holding a person ID (person_...).

Changed

• Protected answers aren't sent to integrations. Answers to fields an admin marked sensitive or masked are left out of custom_fields for API keys and connected apps, and out of every event and webhook. Signed-in people see them only in the roles the admin chose. See Custom fields.

2026-10-01 — Public forms for pre-registration and bookings, and plan historyCopy Anchor Link

Changes to the preview contract, made before anything ships.

Breaking

• Publishable keys pre-register only for open types. POST /visits with a publishable key now needs a type an admin has opened for pre-registration; any other type, including the default meeting when it isn't open, returns validation_failed at body.type. Its custom_fields may contain only the fields asked of the visitor (those in the type's public_form); a field your staff fill in returns validation_failed at body.custom_fields.<key>. See public forms.
• Publishable keys book with the public intake questions only. POST /bookings with a publishable key accepts only the custom_fields in the booking type's public_form; a field your staff fill in returns validation_failed at body.custom_fields.<key>.

Added

• VisitTypeObject gains pre_registration (true when an admin has opened the type for pre-registration; off by default) and public_form ({ version, schema }: the type's visit form with only the fields asked of the visitor, or null unless pre_registration is true).
• Publishable keys can call GET/visit-types and GET/visit-types/{visit_type}. They see only types that are turned on and open for pre-registration; any other type is not_found. GET /forms stays closed to publishable keys. The React <PreRegistrationForm> uses this to fetch its types and questions itself.
• BookingType gains public_form (the same { version, schema } shape): the intake questions asked of the visitor on its visit_type's form, for public booking types; null for private ones. Publishing a booking type makes these questions public, whether or not the visit type is open for pre-registration. The React <BookingWidget> renders them.

Changed

• Plan history in the API. In live mode, your plan's visitor history decides which visits and visitor records the API shows, and its audit-trail period which audit events. Moving to a lower plan never deletes data: older records are kept, hidden, and come back when you move up. Lists leave them out; reading or acting on one by ID returns plan_required, not not_found. Visits that are still expected, awaiting_approval or checked_in are never hidden, and DELETE /visitors/{visitor_id} covers hidden records too. There's no API export of hidden records; an organisation's Owner or Admin can request a full export, including them, from the console on any plan.
• <PreRegistrationForm> needs host. Publishable keys never list or search people, so the planned React component takes the host from your page and shows a message instead of the form without one. For host search, use the embed script, whose hosted page has it.

2026-10-01 — Custom visit types, booking confirmation and MCP client registrationCopy Anchor Link

Changes to the preview contract, made before anything ships. If you generated a client from the first preview, regenerate it.

Breaking

• Visit types are now per organisation. VisitType is no longer a fixed enum. It's a key: the six built-in keys (meeting, interview, delivery, contractor, event, other) plus the keys of types your organisation adds, such as parent_pickup. Keys are lowercase letters, digits and underscores, start with a letter and are at most 40 characters. This applies to type on visits and the visits filter, visit_type on booking types, forms and the forms filter, and every webhook payload that carries them. Treat them as strings. An unknown key, or a type that is turned off, returns validation_failed when you create a visit or change its type. See custom fields.
• Bookings can wait for the host. BookingStatus adds pending, declined and expired to confirmed and cancelled. A booking made on a booking type that requires confirmation starts as pending, holds its slot, and has no visit_id until the host confirms it. Cancel and reschedule work only on confirmed bookings. Bookings gain confirm_by, confirmed_at, declined_at and decline_reason.

Added

• GET/visit-types and GET/visit-types/{visit_type}, scope forms:read, to list your organisation's visit types with their names, whether they're turned on, and their forms.
• Booking types gain requires_confirmation and confirmation_window_hours (default 24).
• POST/bookings/{booking_id}/confirm and POST/bookings/{booking_id}/decline, scope bookings:write. A decline reason is shown to the attendee only with share_reason_with_attendee.
• Events booking.confirmed, booking.declined and booking.expired, for 29 event types in all. booking.created still fires for every booking, with its status.
• Client ID Metadata Documents for MCP clients, as the MCP authorization specification (revision 2026-07-28) recommends: the client's client_id is an HTTPS URL serving its metadata. The server metadata advertises client_id_metadata_document_supported: true. See authentication.

Changed

• Dynamic client registration stays available for MCP clients that don't support metadata documents. The MCP specification now marks it deprecated; Agoo keeps it, and any change will be announced here first.
• Plan access for website embeds, stated precisely: the embed script and the WordPress plugin's blocks work on every plan that has booking pages, because they show hosted pages in a frame. The React components call the API directly, so they need Pro or Enterprise in live mode, and work on every plan in test mode.

2026-10-01 — Preview contract published (v1.0.0-preview)Copy Anchor Link

The first public preview of the Agoo developer platform. The API ships in phase P9; this contract lets you design and build integrations now, in step with it.

Added

• REST API v1 at https://api.agoo.ardent.africa/v1, described in an OpenAPI 3.1 document and in the API reference. Resources: organisation, sites, people, visits (including check-in, check-out, approve, deny, cancel and resend pass), visitors (including erasure under Act 843), deliveries, booking types and availability, bookings, attendance events and summaries, shifts, watchlist, roll calls, webhook endpoints, events, audit events and forms.
• Authentication with secret keys (agoo_sk_live_…, agoo_sk_test_…) and browser-safe publishable keys (agoo_pk_live_…, agoo_pk_test_…), each with scopes. 22 scopes, from organisation:read to forms:read. See authentication.
• OAuth 2.1 for third-party apps and MCP clients: authorization code with PKCE (S256), rotating refresh tokens, dynamic client registration, and admin approval per organisation.
• Test mode on every plan: _test_ keys work on a sandbox copy of your organisation, with messages held in the console's test outbox. See environments.
• Conventions: TypeID identifiers, RFC 3339 timestamps in UTC, E.164 phone numbers, money in minor units, cursor pagination, RFC 9457 problem details with stable error codes, Idempotency-Key on every POST, per-organisation rate limits with RateLimit- headers, and an Agoo-Request-Id on every response. See concepts.
• Custom fields on visits and people, defined per organisation as JSON Schema and readable with GET /forms. See custom fields.
• Webhooks with Standard Webhooks signing, retries for about 27 hours and 26 event types across visits, passes, deliveries, bookings, attendance, the watchlist, roll calls, people and visitors. See webhooks and event types.
• Plan access: webhooks on Growth; the full API, OAuth apps and MCP on Pro; higher limits, custom scopes and IP allow-lists on Enterprise.
• Documentation for planned tools, so you can plan integrations with them: the MCP server, the TypeScript SDK, the webhooks helper, React components, the embed script, the CLI, the WordPress plugin and other languages. Each will be announced here when it's published.

RelatedCopy Anchor Link