Providers that send data

Most Provider Plugins read the Provider on a schedule. Some Providers send their data to Parable instead: a webhook, a telemetry exporter, or an agent on a device. Parable receives each delivery, checks the sender, and lands the records in the same Provider Pool tables as data that a sync reads. protocolType names the wire protocol, such as webhook for webhooks or otlp for OpenTelemetry exporters. Parable Pulse sends data from each Mac through its own agent protocol. See Parable Pulse.

​

Sender verification

A leaf connection method of such a Provider lists supportedInboundAuthStrategies. Each strategy has an id, a label, a verificationType, a handshakeKind, and a configSchema for the secret that verifies the sender: handshakeKind says how the sender confirms the endpoint when you register it: none, slack_url_verification for Slack’s URL verification, or ms_graph_validation_token for a Microsoft Graph subscription. Parable answers the handshake for you.

​

Connect and get an endpoint

1. Create the connection with POST /api/connectors, as in Connect a Provider. Send the id of an inbound strategy as authenticationStrategyId, and the verification secret that its configSchema asks for as authenticationConfig.
2. Parable records the credential as valid when you save it, because there is no Provider API to check it against. Parable checks the sender on every delivery. Saving the credential, then or later, starts no backfill and no schedule.
3. List the connection’s Taps with GET /api/tenant-connector-taps/tenant-connector-taps?tenantConnectorId=....
4. Mint an ingest token for each Tap that a sender delivers to:
   curl -X POST "$PARABLE_API_URL/api/ingest-tokens" \
     -H "Authorization: Bearer $PARABLE_API_TOKEN" \
     -H "X-Tenant: $PARABLE_WORKSPACE" \
     -H "Content-Type: application/json" \
     -d '{ "tenantConnectorTapId": "<id of the Workspace Tap>" }'
   
   The response has token, endpointUrl, and ingestToken, the token’s record. endpointUrl is the full address that the sender posts to, with the token in it.
5. Put endpointUrl in the Provider’s console or the sender’s settings.

Parable shows token and endpointUrl once, and stores only a hash of the token. Keep them where the sender’s configuration lives. A Tap has at most one active token. Minting a second one fails while the first is active.

​

Manage ingest tokens

A token record has prefix, the first characters of the token, to tell tokens apart. It also has lastUsedAt, expiresAt, rotatedAt, and revokedAt. Minting, rotating, and revoking need permission to change the connection’s Taps. To replace a token without a gap, rotate it, update the sender with the new endpointUrl, and let the old token expire.

​

Send data

Each receiver has its own path under the endpoint. Every request is a POST. A webhook body is one JSON object, a JSON array of objects, or JSON Lines, one object on each line. Each request lands every record in it. Parable answers: The rate for each token is 25 requests a second for a webhook and 200 for OTLP, unless the plugin sets its own limit. Send a delivery again when it fails. A plugin keys its records on a stable ID. When the Tap sets deduplicateAcrossLoads, a record that two deliveries carry keeps one row (Tap schemas).

​

See when data arrives

When Parable lands data for a token, it stamps the token’s lastUsedAt, at most once a minute. A refused request never stamps it. The connection’s lastDataReceivedAt is the newest lastUsedAt among its tokens. It is null until the first delivery. Parable moves landed data into the Provider Pool on a schedule. A query can read no rows for a short time after a delivery lands. The API Reference has the full request and response shapes.