AllMoxi ↔ Sibelink API Integration Blueprint (Catalog + Orders Sync)
Learn how to build a reliable AllMoxi ↔ Sibelink API integration for catalog and order sync—with pagination, error handling, and retry logic built in.
How to Send External Metrics to Notion Databases (API, Zapier, Make)
Learn how to push external KPIs into a Notion database using the Notion API, Zapier, or Make. Covers schema design, idempotency, and rate-limit handling.
TABLE OF CONTENTS
This guide shows how to push external KPIs (from tools like PostHog, Sheets, or any analytics source) into a Notion database reliably — using the Notion API directly or middleware tools like Zapier and Make.
To send external metrics into a Notion database, create a Notion integration, share your target database with that integration, then use the Notion API to create (or update) database items on a schedule. For reliability, make the write operation idempotent (so retries don’t create duplicates), handle Notion’s API rate limits, and log failures for retry.
The “metrics → Notion” pattern (what you’re building)
Most metrics pipelines into Notion look like this:
- Source system (PostHog, Stripe, HubSpot, internal CLI logs, etc.)
- Exporter (scheduled job, webhook handler, or middleware scenario)
- Normalizer (map/rename fields into your Notion schema)
- Writer (Notion API call: create/update page in a database)
- Reliability layer (idempotency, retries, backoff, alerting)
Step 1: Design the Notion database schema for metrics
Before wiring anything up, make sure your database supports analytics-like data.
Recommended properties
- Metric name (Title) — e.g., “Daily active users”
- Source (Select) — e.g., PostHog, Stripe, Internal
- Metric date (Date) — the day/week the metric represents
- Value (Number) — the numeric metric
- Unit (Select) — %, $, count, etc.
- External ID (Text) — the unique key from your source (critical for idempotency)
- Notes (Text) — optional context
Two common metric table designs
Option A: One row per metric per time period (recommended)
- Example: one row for “DAU on 2026-04-20”
- Pros: easy charts/grouping; easy upserts
Option B: One row per day with many columns
- Example: columns for DAU, WAU, Revenue, etc.
- Pros: spreadsheet-like
- Cons: schema changes over time; more brittle
Step 2: Choose your delivery method (3 good options)
Option 1 (best long-term): Write to Notion via the Notion API
Use this when you want maximum reliability and control.
When it’s a good fit
- You can run a small script/serverless function
- You care about retries, monitoring, or complex mapping
High-level flow
- Pull metrics from the source API (or your DB)
- For each metric point, find an existing Notion row by External ID + Metric date
- If it exists: update the row
- If it doesn’t: create the row
Option 2 (fastest no-code): Middleware (Zapier / Make)
Use this when you want speed and you don’t need deep control.
When it’s a good fit
- Your source tool can trigger a webhook or send to Sheets
- Your workflow is mostly “map fields → create DB item”
Common setup patterns
- Source tool → Webhook → Zapier/Make → Notion “Create database item”
- Source tool → Google Sheets (append row) → Zapier/Make (watch rows) → Notion
Option 3 (bridge system): Google Sheets as an intermediary
This is the easiest “minimum viable pipeline,” especially if you already have exports going to Sheets.
Pros
- Simple to inspect/debug
- Works with tons of tools
Cons
- Be careful not to treat Sheets as the system of record
- Still needs idempotency (duplicate rows happen easily)
Step 3: Build reliability (idempotency, retries, rate limits)
The difference between a demo and a dependable system is how it behaves when things go wrong.
Idempotency: prevent duplicate Notion rows
If your automation retries a failed run (common), you can accidentally create duplicate database items.
Best practice
- Store a unique key in Notion (e.g.,
External ID+Metric date) - Your pipeline should always “upsert” (update if exists, otherwise create)
Example idempotency keys
posthog:dau:2026-04-20stripe:mrr:2026-04
Rate limits: expect backoff
Notion rate-limits integrations to an average of ~3 requests/second and returns HTTP 429 with a Retry-After header when you exceed limits.1
What to do
- Queue writes
- Use exponential backoff on 429
- Batch or reduce frequency (e.g., write once per hour/day)
Retries: do them safely
- Retry on transient errors (429, 5xx)
- Don’t retry forever — log + alert after N failures
- Make sure retries are safe via idempotency
Step 4: Implementation checklist (copy/paste)
Create Notion integration + store the token securely
Share the target database with the integration
Add properties: Metric date, Value, External ID, Source
Pick your pipeline method (API vs Zapier/Make vs Sheets)
Implement upsert logic using External ID + Metric date
Add retry + backoff handling
Add a run log (even a simple “Runs” table) so failures aren’t silent
Common pitfalls (and how to avoid them)
- Duplicates → add External ID + upsert logic
- Schema drift → keep metrics table narrow; avoid “many columns per day” designs
- Silent failures → log every run + alert on errors
- Over-frequent writes → write less often; aggregate before writing
Get help building your Notion metrics pipeline
If you want help designing a clean metrics schema or setting up a reliable Notion API pipeline, book a free discovery call. We’ll map out the right approach for your data sources and stack.
Related Posts
How to Find Your Notion Workspace ID
A 49-second video and written steps for finding your Notion workspace ID. Log in, click your workspace name, open Settings, then Identity, and copy the ID.
Fix RelayHook concurrent-call responses with UUID request IDs
Fix RelayHook concurrent calls: generate a UUID request ID per webhook call, store it in request context, and route responses by ID to prevent mixups.
