Developer support
How to get help with the Agoo API and developer tools, report a security vulnerability, and follow service status and deprecations.
Get help
Email the Agoo team in Accra at agoo@ardentafrica.com, with "Developer" in the subject so it reaches the right people. You can also use the contact form at agoo.ardent.africa/contact; start your message with "Developer". We reply within one working day.
| Contact | Details |
|---|---|
| agoo@ardentafrica.com | |
| Phone | +233 30 398 3393 |
| Address | 10A Mega Street, Adentan Municipality, Accra, Ghana |
| Company | Agoo by Ardent is founded, designed and developed by Mawuli Dzaka under the Ardent Africa Foundation LBG. |
Paid plans also have the support channels and response targets listed on the pricing page.
Include these details
The more of these you include, the faster we can help:
| Detail | Where to find it |
|---|---|
Agoo-Request-Id | The Agoo-Request-Id response header, or request_id in an error body. Starts req_. The most useful detail of all. |
| Time of the request | In UTC, to the minute if you can. |
| Mode | Test or live. |
| Endpoint, tool or package | For example POST /visits, the MCP tool invite_visitor, or @ardent-africa/agoo and its version. |
| What you expected and what happened | The error code and detail, or the unexpected response. |
| Webhook event ID | For webhook problems, the webhook-id header or the event's evt_… ID. |
Never send secrets
Never include a full secret key (agoo_sk_…), a webhook signing secret (whsec_…), an OAuth token or visitors' personal data in a support message.
To identify a key, give its name or the key's ID from the console. If you've shared a secret anywhere by mistake, revoke it in Console →
Developers and create a new one.
Reporting a security vulnerability
If you believe you've found a security vulnerability in Agoo, the API, the MCP server or any of our developer tools, please tell us privately first.
- Read how to report a vulnerability on our security page, which also explains how Agoo protects data.
- Email agoo@ardentafrica.com with "Security" in the subject. Describe the issue briefly: what's affected and how you can be reached. Don't put exploit details, proof-of-concept code or anyone's personal data in your first message; we'll reply with a way to share them safely. The same address is in our security.txt. If you can't send email, use the contact form and start your message with "Security".
- We'll acknowledge your report within 3 working days and keep you updated while we investigate and fix it.
While investigating, please:
- Test only against your own organisation, preferably in test mode. Never access, change or delete other organisations' data.
- Don't degrade the service for others, for example with load testing or spam.
- Give us reasonable time to fix the issue before telling anyone else.
Service status
status.agoo.ardent.africa checks the API, webhooks, the MCP server once it's live, and every other part of Agoo every minute from outside, and runs separately so it stays up when Agoo doesn't. It shows what's happening now, planned maintenance, 90 days of history and the API's response times. For your own monitoring:
| What | Where |
|---|---|
| Current status (JSON) | GET https://status.agoo.ardent.africa/api/v1/status.json: the overall status, every component and anything open |
| Last 90 days (JSON) | GET https://status.agoo.ardent.africa/api/v1/incidents.json |
| Feed | https://status.agoo.ardent.africa/feed.atom, for feed readers and team chat |
| Badge | https://status.agoo.ardent.africa/badge.svg, for a wiki or service desk |
Both JSON files allow requests from any origin and change at most once a minute; don't poll faster than that. status.indicator is none, minor, major or maintenance. You can also subscribe by email on the page.
If you see errors you can't explain:
- Check the status page first.
- Check the
Agoo-Request-Idand errorcode.unavailable(503) andinternal_error(500) are on our side and safe to retry with backoff; the SDKs do this for you. - Webhook deliveries that fail are retried for about 27 hours, so a short outage on either side doesn't lose events. See webhooks.
- If errors continue, contact us with the details above.
Deprecation policy
- Within
/v1, changes are backwards-compatible: new endpoints, optional fields, enum values and event types can appear without notice, so your code should ignore what it doesn't recognise. - Breaking changes only come in a new major version, such as
/v2, which runs alongside the previous version for at least 12 months. - Deprecations are announced in the changelog with the date the old behaviour stops working.
- During the preview, the contract can still change before general availability. Every change is listed in the changelog.
The full policy is in versioning.