By ChartNothing Product Team · Updated · 9 min read
A practical decision guide for connecting a read-only GET endpoint, a POST-based query, or a signed webhook while keeping credentials, refresh ownership, retries, and latest-state semantics clear.
Choose who owns the clock
The cleanest integration starts by deciding who should trigger an update. If ChartNothing should refresh on a schedule, use a read-only GET or POST connector. If the source already emits meaningful events, use a signed webhook. The transport is less important than having one owner for cadence, retries, idempotency, and cost.
A GET connector suits public or authenticated resources where parameters fit safely in the approved URL and secrets remain server-side. POST suits read-only APIs that require a structured request body, including services such as an exchange info endpoint. A webhook suits event-driven systems, jobs, and trading services that already know when new state exists.
- GET: ChartNothing pulls a resource on a budgeted schedule.
- POST: ChartNothing submits a bounded read-only query body.
- Webhook: your system pushes a signed event when state changes.
Keep authentication behind the connector
Credentials belong in server-side secret storage, not feed records, browser storage, copied cURL examples, or dashboard URLs. Connector records retain a secret reference and a short preview only. Endpoint validation requires HTTPS and blocks private-network targets unless a future explicitly controlled path says otherwise.
Inbound webhooks use a per-source HMAC secret that is shown once on create or rotation. Requests include source, timestamp, signature, event type, and idempotency key. Signature and timestamp validation happen before persistence; valid non-duplicate requests then pass through an atomic per-minute quota before queue delivery.
What happens when data arrives too often
For scheduled pulls, ChartNothing controls the cadence and can avoid unnecessary upstream calls. For webhooks, the sender may push faster than the user's feed or device needs. The ingest API enforces a source and plan rate cap, deduplicates idempotency keys, and queues accepted events. Downstream feed processing keeps a latest usable state instead of promising to render every event forever.
That distinction protects both cost and usability. A watch complication usually needs the newest valid state and its freshness, not a complete event firehose. Bounded run/event history can support debugging and replay, but raw unbounded retention is not the default product model.
Design one payload for many surfaces
A useful universal payload separates current metrics, timestamped series, tabular rows, flow edges, and compact widget fields. It keeps units explicit and stable. Currency, percentage, count, duration, and text should not be mixed on one numeric axis merely because the renderer can draw them.
After the first successful sample, Feed Lab drafts a strict template rather than arbitrary executable code. The user reviews paths, labels, formats, chart types, and native selections before saving. Publishing binds that validated recipe to the latest feed so web and native consumers share one contract.
- Metrics for current values such as balance, latency, or health.
- Series for real timestamped or categorical numeric points.
- Tables for positions, incidents, models, or ranked records.
- Flows for positive numeric edges such as request outcomes or allocation.
- Widget fields for one primary value, one secondary value, and a short state.
Production checklist
Before enabling a schedule, run one manual refresh or signed smoke event and inspect the normalized preview. Confirm units, missing values, timestamps, source ownership, maximum response size, and stale/error behavior. Rotate or revoke the credential and prove the old one fails. Then choose a plan cadence based on the value of freshness, not the fastest number available in a dropdown.
For a private API, create the narrowest read-only credential or endpoint possible. Do not give ChartNothing a full administrator session when a purpose-built token, signed endpoint, or public account method can expose only the required data. This makes the integration easier to explain, rotate, audit, and eventually delete.
Frequently asked questions
Should I create an endpoint or send a webhook?
Prefer an endpoint when ChartNothing should own cadence and the source can answer a safe read-only request. Prefer a signed webhook when your system already knows exactly when meaningful state changes.
What if I push every minute but only pay for daily updates?
The source rate cap and plan budget apply. Accepted processing should preserve the latest usable state; ChartNothing does not promise to store or deliver every raw event indefinitely.
Can ChartNothing call an authenticated private API?
Yes, when the endpoint is HTTPS, safely allowlisted, and uses a narrowly scoped server-side credential. Full administrator sessions and browser-exposed secrets are not appropriate.