Activity Messenger Help Center

API introduction

Use the Activity Messenger API from your server to connect organization data or publish website content. Start here for connection details and shared conventions, then choose a resource reference below.

Authentication and base URL

Send all requests to https://activitymessenger.com/api/v1/organization/{organization}. Replace {organization} with the numeric organization ID. A website’s custom domain is not the API host.

Obtain your organization API key from Organization settings → Web & integrations → API keys / MCP tokens. Send it in the X-Activity-Messenger-Api-Key HTTP header. Keep it in server-side secret storage; do not embed it in browser JavaScript, URLs, or public repositories. Send Accept: application/json; for JSON request bodies, also send Content-Type: application/json. File uploads use multipart form data instead.

New API keys apply to the issuing organization by default. Partner-network access is optional; see below. The Website API requires a direct key for the organization in the URL, with websites enabled; it never inherits partner access. A newly issued API key can access all websites owned by that organization and is not read-only. Migrated Stripe App credentials do not authorize Website publishing.

Create and manage API keys

Only account owners and organization owners can issue, view or revoke API keys and manage MCP tokens. Other permission levels, including HR and Admin, cannot manage them.

1. Open Organization settings → Web & integrations → API keys / MCP tokens.
2. Click Add a key / token to open the creation modal. Choose API key as the Credential type.
3. Enter a descriptive Name, such as “Registration integration”, and a Validity in days from 1 to 90. The default is 30 days.
4. Leave Allow access to partner organizations unchecked unless the integration needs the partner network. This option requires an organization that belongs to a partner network.
5. Click Add a key / token, then copy the key into the integration’s protected server-side storage.

Use a separate named key for each integration. API keys permit reads and changes supported by their endpoints; they have no read-only option. They are organization credentials, so removing the issuing user does not revoke them.

To view an existing, unrevoked key again, click Show API key in its row. A modal lets an owner view and copy the encrypted stored key. Showing an expired key does not reactivate it. MCP tokens cannot be shown again after their creation modal closes.

Search by name and use Status to find active, expired or revoked credentials. The list also shows the issuer, creation date, expiry and last use. To replace a key, create a new one, update the integration, verify it works, then click Revoke on the old key and confirm. Revocation immediately blocks subsequent authentication and cannot be undone. Create a replacement before a key expires.

Optional partner access

Allow access to partner organizations grants organization API access to all organizations in the same partner network. It is a setting on the key, not a query parameter sent with each request. Continue putting the target organization’s ID in the request URL.

An owner can change an existing key’s scope from its Organization scope button in the list: This organization or Partner network. Confirm the scope change. Disabling partner access stops integrations using that key for other organizations. Changes to network membership affect which organizations the key can access. Website publishing always stays restricted to the issuing organization.

Existing keys

Existing organization API keys appear in the same list without a change to their value or an added expiry. They retain their previous partner-network access. You can show them, limit their scope or revoke them using the same controls as new keys. Revoking a migrated shared key also stops partner access through that key.

Existing Stripe App credentials are also listed and can be revoked for the selected organization. Before revoking any shared credential, update the integrations that still use it.

API keys and MCP Bearer tokens

Use API key for the organization and Website APIs, and MCP token for a manual MCP connection. These are different credentials. “Bearer” describes how an MCP token is sent: Authorization: Bearer <mcp-token>. An API key sent in X-Activity-Messenger-Api-Key cannot authenticate MCP.

See Connect an AI assistant with MCP for manual tokens and OAuth connections. The IFRAME settings page contains embedding settings and a link to key management; it no longer displays the API key.

Make a first request

Read organization information with GET /api/v1/organization/{organization} and the headers above. Resource references show HTTP methods and paths; replace placeholders with the IDs returned by the API. IDs, external page keys, slugs, and membership numbers are distinct identifiers: use the identifier documented for each endpoint.

Pagination

Pagination depends on the endpoint; do not assume every collection has the same response shape.

• Optional pagination: users, members, forms, form tags, classes, and class tags return an array of at most 50 items when neither page nor per_page is supplied. Supply either parameter to receive a paginator with data, current_page, next_page_url, and totals. The default is 50 items; the maximum is 250.
• Published messages and templates: always paginated, with 10 items per page by default. Set per_page and page as needed.
• Form respondents: always simple pagination; default 50, maximum 250. There is no total, last_page, or last_page_url.
• Website lists: websites, pages, and assets always use simple pagination at a fixed 50 items per page. Use page; per_page does not change the page size. There are no totals.
• Other collections: products, product tags, and booking packages return arrays. Calendar events use date-range filters. See the resource reference before adding pagination parameters.

For paginated responses, process data and stop when next_page_url is null. Retain the original filters and page size on subsequent requests; returned links may not repeat every query parameter. Send authentication on every request. Avoid logging the key or sensitive response data.

Rate limits and retries

The application API is configured for 240 requests per minute. Website routes also apply a 60-request-per-minute throttle. These are shared limits, not independent allowances per endpoint or organization key. Ordinary API-key requests are throttled by the caller’s IP address; integrations behind the same outbound address can share capacity.

Inspect X-RateLimit-Limit and X-RateLimit-Remaining when present. On HTTP 429, wait at least the number of seconds in Retry-After before retrying. Reduce concurrency and use bounded retries with backoff for temporary failures. Do not repeatedly retry authentication or validation errors.

Do not blindly retry writes after a timeout: the operation may already have succeeded. Website revision staging and publication have documented idempotency guarantees; other mutations do not share that guarantee. Read the resulting state before deciding whether to repeat a write.

Responses and errors

Successful calls return endpoint-specific JSON: an object, array, or paginator. Check the HTTP status before processing the body. Do not assume every error uses the same envelope; older organization endpoints can return a JSON string or null.

• 401: missing or invalid API credentials. Check the key, expiry, revocation, partner scope and target organization.
• 404: resource unavailable or inaccessible. Check IDs and ownership; Website access also requires the feature to be enabled.
• 409: a Website revision or redirect baseline is stale. Read the current state, reconcile the change, and review a new request.
• 413: the request is too large. Website document requests have a 2 MB limit; image upload limits are documented separately.
• 422: invalid input or an unsupported operation. Validation responses may include message and field-level errors; correct the request before retrying.
• 429: rate limit reached. Honor Retry-After.

Dates, filters, and updates

Use the formats documented for each parameter. A timestamp ending in Z is UTC; a business-date filter such as YYYY-MM-DD is not a UTC instant. Follow the endpoint’s organization-timezone and date-boundary rules. Array filters use brackets such as tags[]=swimming. Preserve the distinction between omitted fields, null, and empty arrays, especially when replacing content or attendance.

Organization API references

• Organization and network
• Staff and permissions
• Members and check-ins
• Forms and respondent exports
• Classes and calendars
• Attendance
• Booking packages
• Products
• Published messages and templates

Website API references

• Publish pages: discovery, full documents, revision review, publication, and deletion.
• Assets, shared sections, and redirects: image manifests, reusable navigation, and redirect replacement.

Endpoint index

Every endpoint documented in these references. Organization API paths are relative to https://activitymessenger.com; Website API paths are relative to /api/v1/organization/{organization}/websites/{website} unless shown in full.