Reference · built on requestConnectorSensors, meters & gateways

Particle

Devices, variables, published events, device vitals, and webhook integrations from the Particle Cloud API.

Request accessPricing ↗

About

Particle makes cellular and Wi-Fi modules and runs the device cloud they report to. The Cloud API at api.particle.io lists the devices in a product, reads the variables and calls the functions a device's firmware exposes, streams published events over Server-Sent Events, and keeps the last vitals payload per device. Products group devices into named device groups. Ledger holds JSON per device, product, or owner, up to 16 KB when it synchronizes with devices.

An operator on Fibric watches the event stream and the vitals and proposes the function call, the ledger change, or the ticket for your approval.

This is a reference listing. It documents what Fibric would read from Particle 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

  • Devices in a product through GET /v1/products/:productIdOrSlug/devices, with online, last_heard, firmware_version, groups, serial_number, iccid, and quarantined
  • Events published by devices, streamed as Server-Sent Events from GET /v1/products/:productIdOrSlug/events and filtered by event name prefix
  • Variable values a device exposes through GET /v1/devices/:deviceId/:varName, with connected and last_handshake_at in coreInfo
  • Device vitals through GET /v1/diagnostics/:deviceId/last, covering network, cloud, power, and system metrics; history expires after 1 month
  • Ledger instances scoped to a device, product, or owner through GET /v1/ledgers/:ledgerName/instances/:scopeValue
  • Webhook integrations and their hook-sent, hook-response, and hook-error events; device groups with fw_version and device_count

Proposed actions

  • Target capability: propose a function call through POST /v1/devices/:deviceId/:functionName with an arg of up to 63 characters
  • Target capability: propose a device rename, note, or forced firmware update through PUT /v1/devices/:deviceId
  • Target capability: propose setting Ledger instance data through PUT /v1/ledgers/:ledgerName/instances/:scopeValue
  • Target capability: propose publishing a product event through POST /v1/products/:productIdOrSlug/events with name, data, and ttl
  • Target capability: propose a Webhook integration through POST /v1/integrations with integration_type, event, url, and requestType

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

What you can build

  • Catch the device that went quiet

    Read online and last_heard for every product device and the last vitals payload. When a device misses its expected check-in, propose the ticket and the ping for approval.

    With Sensor Health, Data Freshness

  • Act on a threshold event

    Subscribe to the product event stream under an event prefix. When a published value crosses your limit, propose the function call that changes the device's state, with a note for the record.

    With Cold Chain Excursion, Leak Response

  • Push a setting to the fleet

    Keep the schedule or setpoint in a Cloud to Device ledger. Propose the change to a device, product, or owner instance; devices pick it up when they next connect.

    With Setpoint Drift

Requirements

  • A Particle product; device groups and Ledger are product features and are not available to individual developer devices
  • An API user created through POST /v1/products/:productIdOrSlug/team with a friendly_name and the scopes it needs
  • TLS 1.2 or later to api.particle.io; requests as JSON or form-encoded, responses as JSON
  • Device OS 6.1.0 or later on devices that sync Device to Cloud or Cloud to Device ledgers
Authentication
A Bearer access token in the Authorization header, issued to an API user scoped to a product or organization with named scopes such as devices:list and devices.function:call.

Limits

  • 10,000 requests every 5 minutes per source IP across the API; Server-Sent Events subscriptions: 100 requests every 5 minutes and 100 open connections
  • Publishes are not confirmed to recipients; an event can arrive twice or out of order, so payloads need their own identifier
  • A webhook response is chunked into 512-byte pieces and dropped past 10 chunks; the target must answer within 20 seconds
  • Synchronized Ledger instances hold up to 16 KB of JSON; cloud-only ledgers hold up to 1 MB

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 Particle ↗

Questions and answers

How does Fibric receive Particle events?
Two documented routes. A Server-Sent Events stream on GET /v1/products/:productIdOrSlug/events, filtered by event name prefix and limited to 100 subscriptions every 5 minutes. Or a Webhook integration that sends each matching event to a URL you name. Both carry the event name, data, published_at, and coreid.
Can Fibric change what a device does?
Only through what the firmware exposes. A function call goes to POST /v1/devices/:deviceId/:functionName with an arg of up to 63 characters and returns return_value. A Cloud to Device ledger carries JSON the device reads on its next sync. Both are proposed for approval first.
What are the rate limits?
10,000 requests every 5 minutes per source IP for the API as a whole. Creating access tokens, listing events, and opening Server-Sent Events streams are each limited to 100 requests every 5 minutes, with at most 100 open streams. Serial number lookup is 50 requests per hour. Excess returns 429.
Ask about Particle

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 Particle 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