Changelog

Changes that affect integrators are recorded here. Within v1, expect only additive changes (new endpoints and new fields). Breaking changes ship under a new version.

2026-08: Durbar across the toolchain

Durbar, our live audio rooms, is now on every integration surface. This page previously carried the opposite: the developer index said Durbar had no public API and that we would rather ship nothing than ship a read-only listing that implied more. That reasoning was about joining a room, and it still holds. Reading one was never the problem.

• API. GET /durbars, GET /durbars/{slug} and GET /durbars/{slug}/transcript. The list covers public rooms; an unlisted durbar stays reachable by slug, because that is what its host shared, and is absent from the index, because an index any key can page through would publish every one of them at once. A cancelled room is never published at all.
• Listener counts are null until a room ends, and null is not 0. A live room's peak moves, so a figure published mid-room drops when somebody refreshes, which reads as a room emptying out. Substituting 0 for null claims nobody came.
• Speakers are named; listeners never are, at any tier. A speaker talked in public into a recording that is itself public and indexed. A listener did the opposite. Raised hands are not readable by this surface at the database level, because knowing that somebody asked to speak in a known room identifies them, and a request a host declined is a private fact.
• Transcripts, with a warning attached to the payload rather than to a footnote. Every response carries a disclaimer field. This is speech recognition of multi-speaker Ghanaian English that code-switches into Twi, Ga, Ewe and Pidgin: names, places and switched passages are frequently wrong. Segments carry a confidence and carry no speaker attribution, so a line must not be presented as a quotation from a named person.
• MCP. list_durbars, get_durbar and get_durbar_transcript. The same trip in the same release also fixed a real defect on that surface: the tool list is generated from the OpenAPI document while the handlers were hand-written, so list_surveys, get_survey and all six social tools were advertised and returned "Unknown tool" when called. Twenty-eight tools were offered and seventeen worked. A parity test now fails the build if the two ever diverge again.
• SDKs. listDurbars, getDurbar, getDurbarTranscript in both the JavaScript and PHP clients, with full types on the JS side.
• oEmbed and widgets. Paste an ardent.africa/durbar/<slug> link, or use data-ardent-durbar. The card renders whatever state the room is in, because a scheduled room is the one people most want to share.
• WordPress. [ardent_durbars] and [ardent_durbar], matching blocks, and Elementor widgets.
• Zapier. A New Durbar trigger, watching scheduled rooms by default.

No join, and there will not be one. Joining mints a short-lived token scoped to a room, an identity and a permission set. An API key has no actor, no trust level, no block relationships and nobody to show a recording consent notice to. Reading about a public room is a public act; entering one is not.

2026-08: Polls & Surveys across the toolchain

The Polls & Surveys domain is now on every integration surface:

• API. GET /surveys and GET /surveys/{slug} return what a survey asks and how many people answered. Individual responses are never returned, and on an anonymous survey they do not exist to be returned: nothing is stored linking a response to a person.
• SDKs. listSurveys / getSurvey in both @ardent-africa/sdk and ardent-africa/sdk.
• oEmbed + widgets. Pasting a /polls/... link auto-renders as a poll card. The card shows the question and links out to answer: it never collects an answer inside a third-party page, because a respondent has to see the privacy notice first.
• MCP. list_surveys and get_survey.

response_count is number | null, and the null is load-bearing. A survey that does not publish its results yet returns null, not 0, because zero would be a claim that nobody has answered. Branch on results_revealed before showing a figure.

Only public, standalone surveys appear. An unlisted survey is as private as its link, and a registration form attached to an event belongs to that event's flow.

One more thing if you consume /posts:

• attachments[].type is an open set, and always was. A post can point at a campaign, petition, event, job, listing, business or review today, and a poll or survey once the feature is switched on. If your integration branches on type, make sure the default branch renders something sensible rather than throwing. The shape of each attachment (type, title, url) does not change.

All additive on the existing v1 contract: no endpoint removals and no response-shape changes.

2026-07: Jobs & Reviews across the toolchain

The public Jobs and reviewed entities (TrustScore) domains are now first-class on every integration surface, not just the raw API:

• SDKs. @ardent-africa/sdk 1.1.0 adds listJobs/getJob and listReviewEntities/getReviewEntity; the PHP ardent-africa/sdk 1.1.0 adds the same four methods.
• oEmbed + widgets. Pasting a /jobs/... or /reviews/... link now auto-renders, and there is a new job embed widget alongside the existing review one.
• WordPress. The Ardent Africa plugin 1.3.0 adds Jobs-list and TrustScore blocks, [ardent_jobs] / [ardent_review] shortcodes, and matching Elementor widgets.
• Webhooks. The review and entity event types are now subscribable: review.received, review.flagged, review.responded, entity.claim.submitted, entity.claim.approved, entity.question.asked, entity.update.published, entity.suggestion.submitted, and entity.verification.approved (the job events job.posted / job.closed / application.received / application.status_changed remain available).

All additive on the existing v1 contract: no endpoint removals and no response-shape changes.

2026-06: SDKs & automation

• Published official SDKs: @ardent-africa/sdk for JavaScript/TypeScript and ardent-africa/sdk for PHP: typed, read-only clients over /public/v1.
• Released the official Zapier app with polling triggers (New Campaign / Petition / Event) and slug searches.
• Added a downloadable, version-controlled copy of the OpenAPI spec alongside the live /openapi.json endpoint.

No endpoint or response-shape changes: all additive tooling on the existing v1 contract.

v1.0 (initial release)

• Introduced /public/v1.
• Endpoints: campaigns, campaigns/:slug, petitions, petitions/:slug, blog, blog/:slug, profiles/:username, stats.
• Two rate tiers: 30 requests/minute keyless (per IP), 600 requests/minute keyed.
• Embeddable widgets: campaign, compact card, and petition, via iframe or script tag.
• Cross-origin GET enabled for /public/v1 so the API can be called from the browser.

Last updated: 24 August 2026