Skip to main content
​
Removing the API key’s own owner from the Network now returns 403DELETE /admin/v1/networks/:network_id/members/:id/network_membership now returns 403 with the standard error response body when :id is the user who owns the API key. Before, the request removed the key owner from the Network and returned 204. The Mighty web and mobile apps never let a Host remove themselves this way, and the API now follows the same permissions.Removing any other member works as before. To remove the key owner, use an API key owned by a different Network Host. This is a security change, so it ships without the notice period in our deprecation policy.
​
Some post and event writes now return 403Deleting and editing now follow the same permissions as the Mighty web and mobile apps for the user who owns the API key. When a request is refused, the API returns 403 with the standard error response body. Before, a valid Network Host API key was enough for these writes.These requests now return 403:
  • DELETE /admin/v1/networks/:network_id/posts/:id for forked posts and announcements.
  • DELETE /admin/v1/networks/:network_id/events/:id for forked events and announcement events.
  • PATCH /admin/v1/networks/:network_id/events/:id for another member’s event in a Space where the key owner holds no role, for a Zoom meeting or webinar event created by another member in any Space including the Network itself, and for forked events and announcement events. This applies to every request body, including one that only changes dates, location, link, time zone, event_type, or rsvp_enabled.
Deleting any other post or event in your Network, and editing events the key owner can edit in the app, work as before. If your integration edits events across Spaces, give the key owner a Host or Moderator role in those Spaces, or expect 403 for events you can’t edit in the app.
​
Multi-location Custom Profile FieldsCustom Profile Fields now accept response_type: multi_location, a location field a member answers with several places at the level set by location_granularity. Creating one requires location_granularity and max_responses, the most places one member may add.POST /admin/v1/networks/:network_id/custom_fields/:custom_field_id/members/:member_id/answers accepts locations, a list of { label, latitude, longitude } objects, for these fields. The list replaces the member’s stored places; an empty list clears them and returns 204 No Content. A request without locations leaves the member’s places unchanged; these fields don’t accept text, latitude, or longitude. A successful write returns the member’s whole answer as { member_id, custom_field_id, locations, last_edited_at } with no answer id, since no single row is the answer. The endpoint’s 200 response is now documented as one of two schemas: CustomFieldAnswerResponse for every other field type, CustomFieldAnswersResponse for a multi-location field.On a multi-location field, GET .../answers lists one answer per place, and GET .../answers/:id returns one of them. Each is shaped like a single-location answer (text, latitude, longitude), so the place’s label comes back as text on these reads.The Custom Profile Field response webhooks carry the places too: locations on CustomFieldResponseCreated and CustomFieldResponseRemoved, and previous_locations / new_locations on CustomFieldResponseUpdated.
​
primary_media is now a documented completion_criteria valueThe completion_criteria field on coursework items now documents primary_media as an accepted value. A lesson with this criterion is complete when a member finishes the native audio or video at the top of the lesson. You can set it on the create and update requests at /admin/v1/networks/:network_id/spaces/:space_id/courseworks.A lesson with the primary_media criterion reports primary_media while its primary media slot holds native audio or video. If the slot holds none, the lesson reports button, the same as in the Mighty web and mobile apps, where members finish it with the “Mark as Complete” button. The lesson object in the member.lesson.complete webhook payload reports the same values.
​
A deprecation policy for the Admin APIWe now publish a deprecation policy that sets out how we handle breaking changes to the API. We announce a deprecation at least three months before we deploy the breaking change, record the deprecation and its replacement on this changelog, mark the deprecated field in the OpenAPI spec, and notify you in-app if we detect that your integration still uses it. Security updates, critical bug fixes, and changes required to protect the reliability or integrity of the platform are outside that notice period.The policy also defines what we count as a breaking change for REST endpoints and which additions are compatible, so you can tell from a changelog entry whether you need to act.
​
Create limited members via the APIPOST /admin/v1/networks/:id/members now accepts a member_type parameter so you can create either a full or limited Network member.When creating a limited member, you must specify at least one space ID at the time of creation. A member’s status follows the plans they’re on: a limited member is automatically upgraded to a full member when added to a plan that includes Network membership, and reverts to a limited member when that plan is removed. For more on the difference, see What is a full vs. limited membership?.
​
Automatic disabling of failing webhooksWebhooks that consistently fail to deliver are now automatically disabled to protect your integration and reduce unnecessary traffic. A webhook is disabled after 5 consecutive delivery failures spanning at least 3 days — brief outages will not trigger a disable.When a webhook is disabled, the creator of the webhook receives a notification with a link to the webhook settings page. To re-enable a disabled webhook, update the endpoint URL or verify your server is reachable, then save the webhook settings form.
​
New webhook: gift_leaderboard.updatedAdded a new webhook event triggered when a gift leaderboard is recalculated for your Network. The payload includes the leaderboard type (received or sent), the gift definition for per-definition leaderboards, and leaderboard entries grouped by aggregation period.
​
Optional welcome email for member creationAdded a new optional send_welcome_email parameter to POST /admin/v1/networks/:id/members. Set to false to skip sending the welcome email when adding members programmatically. Defaults to true to maintain backward compatibility.
​
Improved welcome email for API-created membersMembers created via POST /admin/v1/networks/:id/members now receive a welcome email with a direct sign-in link (valid for 1 year), removing the need to go through the password reset flow.
​
General Availability releaseThe Admin API has exited beta and is now generally available. Key updates in this release:
  • Webhook event selection: New UI in the Mighty Networks dashboard to select which webhook events you want to receive, giving you fine-grained control over webhook deliveries
  • API key revocation: You can now revoke API keys instead of deleting them, making it easier to disable access while preserving key history
  • Usage quotas: API quota limits are now visible in the dashboard, with clear usage tracking
  • Business plan availability: The Admin API is now available to all Business plan and above Networks
​
Full CRUD operations and expanded resourcesThis update significantly expands the API with complete create, read, update, and delete operations across all major resources:New endpoints:
  • Comments: Full CRUD for post comments (/posts/:id/comments)
  • Badges: Create, manage, and assign badges to members
  • Reactions: Add and remove reactions on posts and comments
  • Coursework: Full CRUD for course content
  • Polls & Questions: Create and manage polls with question options
  • Assets: Upload images and files via multipart form-data
  • Plan invites: Create and manage plan invitation links
  • Abuse reports: Read abuse reports for moderation workflows
Enhanced queries:
  • Query spaces by member (/members/:id/spaces)
  • Query plans by member (/members/:id/plans)
  • Query members within a plan (/plans/:id/members)
  • Get member by email address (/members?email=...)
Updated resources:
  • Spaces now support full CRUD (create, update, delete)
  • Collections now support create and update
  • Tags now support full CRUD
  • Custom field options now support full CRUD
  • Members now support update and remove operations
  • Posts now support update and delete
  • Plan members can be removed immediately or at end-of-cycle
Webhook improvements:
  • New course progress webhooks: course.progress_updated, course.completed
  • New subscription webhooks: subscription.renewed, subscription.plan_changed
  • New RSVP webhooks: rsvp.created, rsvp.updated, rsvp.deleted
  • More granular custom field webhooks: custom_field.created, custom_field.updated, custom_field.deleted
  • Added bio field to member.updated webhook payload
​
Alpha preview launchInitial release of the Mighty Networks Admin API in alpha preview. This release establishes the foundation for programmatic access to your Mighty Network.Core endpoints:
  • Members: List and retrieve member profiles
  • Spaces: List and retrieve spaces in your Network
  • Events: List events and manage RSVPs
  • Posts & Articles: List and create posts and articles
  • Custom fields: Read custom profile fields and member answers
  • Tags: List and assign member tags
  • Plans: List pricing plans and add/remove members
  • Subscriptions: View subscription details
  • Purchases: View purchase history
Webhooks: Real-time notifications for key events in your Network:
  • Member events: member.created, member.updated, member.deleted
  • Membership events: join, leave, update, join requests
  • Content events: post, article, question, and comment creation
  • Payment events: purchases and cancellations
  • Event RSVPs and poll responses
  • Reaction events
  • Content moderation reports
API foundations:
  • Bearer token authentication with API keys
  • v1 API versioning (/admin/v1/...)
  • Cursor-based pagination
  • Rate limiting with clear quota headers
  • OpenAPI specification for client generation