Reference · built on requestConnectorAccess control & video

ButterflyMX

Door releases, video calls, tenants, units, devices, and visitor keys from ButterflyMX through the v4 API and webhooks.

Request accessPricing ↗

About

ButterflyMX is a video intercom and property access platform for multifamily and commercial buildings. Its v4 API models Buildings, Units, Tenants, Devices, Access Points, Access Tools (PINs and RFID tags), Access Groups, Keychains, and Virtual Keys. Building Integrations and Tenant Integrations post webhooks for door_release and call events. Authorization is OAuth 2.0, against a sandbox at api.na.sandbox.butterflymx.com and production at api.butterflymx.com.

Through Fibric, an operator reads access logs, call logs, and tenant records, then proposes a door release, a visitor key, or a tenant change for your approval. The connector makes one call and leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from ButterflyMX and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Access logs from GET /v4/buildings/{building_id}/access_logs: logged_at, access_point, release_status, entry_method, name, unit, and a snapshot image_url
  • Call logs from GET /v4/buildings/{building_id}/calls with notification_type, recipient, unit, device, status, and a video thumbnail
  • Webhook posts for door_release and call events, bound through a Building Integration or a Tenant Integration
  • Buildings, Units, and Tenants, including a building's configuration options from GET /v4/buildings/{id}/capabilities
  • Devices and Access Points, with the schedules during which an access point can be used
  • Access Tools (PINs and RFID tags) and Access Groups that grant tenants and staff access to parts of the property at set times
  • Keychains and Virtual Keys with type, duration, owner, recipient, and usage statistics

Proposed actions

  • Target capability: propose a door release through POST /v4/door_release_requests for an access_point_id or a device_id
  • Target capability: propose a visitor key through POST /v4/keychains/custom, /v4/keychains/one_time, /v4/keychains/recurring, or /v4/keychains/delivery_pass
  • Target capability: propose creating, updating, or deleting a Tenant, or resending the invitation email to a tenant still in invited status
  • Target capability: propose a PIN access tool through POST /v4/access_tools/pins, a PIN change through PUT, or removal through DELETE /v4/access_tools/{id}
  • Target capability: propose adding or removing tenants and units on an Access Group

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Pre-register a visitor

    A guest is expected Friday evening. The operator proposes a custom keychain for that window and, on your approval, creates the virtual key, which ButterflyMX sends to the guest by email or SMS.

    With Visitor Pre-Registration

  • Revoke access at move-out

    A lease ends. The operator lists the tenant's access tools and open virtual keys, then proposes deleting them and the tenant record on the move-out date.

    With Access Offboarding

  • Set up a move-in

    A new resident joins a unit. The operator proposes the tenant record, a PIN access tool, and access group membership, then a resend of the invitation if status stays invited.

    With Move Coordination

  • Watch delivery traffic at the door

    door_release webhooks carry entry_method, and delivery pass keychains show courier use. The operator spots the busy hours and proposes a package-room or staffing notice.

    With Package Overflow

Requirements

  • A sandbox account, issued by ButterflyMX after an NDA and its Developer Terms; the client id and secret arrive by email
  • Approval of the integration by ButterflyMX before production, then activation per building, requested by building staff through a ButterflyMX form
  • A Building Admin Account as resource owner for building-level endpoints; calls and virtual keys for a resident need that tenant's own login
  • An HTTPS endpoint that answers webhook posts with 200 OK within 5 seconds, or ButterflyMX retries
Authentication
OAuth 2.0 authorization code flow: a Building Admin Account or a Tenant Account signs in as resource owner, and the resulting access token is sent as a Bearer header.

Limits

  • Access tokens last 24 hours; refresh tokens do not expire. One client id and secret per environment, sandbox and production
  • For the production environment ButterflyMX provides one Building Admin Account per building, and admin accounts cannot create other admin accounts
  • RFID tag access tools cannot be updated; delete and recreate instead. Six-digit PINs may not be sequences or repeated digits
  • Live video and two-way calls run through the ButterflyMX SDK, not the API. This listing reads call records; it does not answer calls

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request ButterflyMX ↗

Questions and answers

Does ButterflyMX send webhooks?
Yes. Create a Building Integration at POST /v4/buildings/{building_id}/integrations or a Tenant Integration at POST /v4/tenants/{id}/integrations, with integrator set to webhook, a url, and bindings for door_release and call on the create action. Each payload carries resource_type, action, and the record.
What is the difference between an Access Tool and a Virtual Key?
An Access Tool gives a person permanent access: a PIN or an RFID tag such as a keyfob, keycard, or vehicle sticker. A Virtual Key is temporary, issued from a Keychain of type custom, recurring, one-time, or delivery pass, and shared with a guest by email or SMS.
How do you move from sandbox to production?
Build and test against the sandbox first. ButterflyMX reviews the integration, then gives you a form that building staff submit to switch it on for their property. Production uses a separate client id and secret from the sandbox pair.
Ask about ButterflyMX

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with ButterflyMX through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy