meterflow 0.4.0 → 0.4.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +28 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -354,7 +354,7 @@ try {
|
|
|
354
354
|
|
|
355
355
|
## Verifying webhooks
|
|
356
356
|
|
|
357
|
-
MeterFlow notifies your app of
|
|
357
|
+
MeterFlow notifies your app of activity you'd otherwise poll for — credits granted or deducted, usage recorded, subscriptions created or updated. Every delivery is signed with **HMAC-SHA256** in the `X-MeterFlow-Signature` header, using the webhook's secret — verify before trusting:
|
|
358
358
|
|
|
359
359
|
```typescript
|
|
360
360
|
import express from "express";
|
|
@@ -382,6 +382,33 @@ Details that matter:
|
|
|
382
382
|
- **Verify the raw bytes.** If you `JSON.parse` first and re-stringify, key ordering/whitespace changes and the signature won't match. `express.json()` users: configure it with a `verify` callback to keep `rawBody`, or use `express.raw` on the webhook route as above.
|
|
383
383
|
- The comparison is **timing-safe** (`crypto.timingSafeEqual`) and returns `false` on any mismatch — it never throws on bad input.
|
|
384
384
|
|
|
385
|
+
### Payload shape & event types
|
|
386
|
+
|
|
387
|
+
Every delivery is a flat JSON object (`Content-Type: application/json`) with two envelope fields — `event` (the type) and `environment` (`"live"` or `"test"`, matching the mode of the API key that caused the activity) — plus type-specific fields:
|
|
388
|
+
|
|
389
|
+
| `event` | Fired when | Extra fields |
|
|
390
|
+
|---|---|---|
|
|
391
|
+
| `usage.recorded` | a usage event is ingested (single or batch) | `customer_id`, `event_name`, `value`, `event_id` |
|
|
392
|
+
| `credit.granted` | credits are granted | `customer_id`, `amount`, `balance_after`, `transaction_id` |
|
|
393
|
+
| `credit.deducted` | credits are deducted | `customer_id`, `amount`, `balance_after`, `transaction_id` |
|
|
394
|
+
| `subscription.created` | a subscription is created | `customer_id`, `plan_id`, `subscription_id`, `status` |
|
|
395
|
+
| `subscription.updated` | a subscription is updated | `customer_id`, `subscription_id`, `status` |
|
|
396
|
+
|
|
397
|
+
For example, a `credit.granted` delivery:
|
|
398
|
+
|
|
399
|
+
```json
|
|
400
|
+
{
|
|
401
|
+
"event": "credit.granted",
|
|
402
|
+
"environment": "live",
|
|
403
|
+
"customer_id": "cust_123",
|
|
404
|
+
"amount": 500.0,
|
|
405
|
+
"balance_after": 1250.0,
|
|
406
|
+
"transaction_id": "9b2f6c1e-…"
|
|
407
|
+
}
|
|
408
|
+
```
|
|
409
|
+
|
|
410
|
+
When registering a webhook you pick which of these event types it should receive. Deliveries are retried with backoff on non-2xx responses — respond `200` quickly and do the heavy work asynchronously.
|
|
411
|
+
|
|
385
412
|
Webhooks are registered per-project in the dashboard, which is also where you'll find the secret and each delivery attempt's status.
|
|
386
413
|
|
|
387
414
|
## Using the SDK in a browser
|