Credit-Based API Metering

Under metered access, the unit of purchase is the successful call. MarineTraffic's AIS API requires a contract that meters successful calls as credits, and every key is technically capped at 100 total requests per minute regardless of plan tier - so throughput planning happens in credits-per-vessel-visit, not in bandwidth.

Free sources meter too; they just express it as quotas. Global Fishing Watch allows 50,000 requests/day and 1,500,000/month per user alongside its commercial delivery terms-NC 4.0 terms. BarentsWatch's Norwegian Coastal Administration feed sits in a middle position: NLOD-licensed and free, but clients must contact BarentsWatch before high-traffic usage, which may incur server handling fees. Across the marine slice the pattern holds - the constraint is never whether data exists, it is how many times you may ask for it.

Metering converts architecture directly into cost. A polling design that made sense against a flat-rate internal service becomes a monthly invoice line when every 200 response burns a credit.

• Cache discipline pays twice. With 100 requests/minute per key, unbounded retry loops exhaust quota and budget simultaneously.
• Failed calls still cost engineering time even where only successful calls are metered, because rate-limit errors stall pipelines mid-backfill.
• Quotas differ by orders of magnitude: 50,000/day on Global Fishing Watch versus a contract-defined credit pool on MarineTraffic - sizing a fleet-tracking feature against the wrong number kills the project either way.
• Notification thresholds are contractual. Skipping BarentsWatch's pre-high-traffic contact risks fees appearing after the traffic, not before.

1. Ask what counts as a billable unit. MarineTraffic meters successful calls as credits; clarify whether errors, empty results and pagination count before you model spend.

1. Get the per-key rate ceiling in writing. 100 total requests per minute per key is the documented technical cap - confirm it survives your contract negotiation unchanged.

1. Compare published daily quotas across candidates. Global Fishing Watch states 50,000 requests/day and 1,500,000/month per user; a source without published numbers cannot be capacity-planned.

1. Identify notification duties for heavy use. BarentsWatch requires contacting the publisher before high-traffic usage, which may incur server handling fees - build that email into your launch checklist.

1. Price the alternative access path. Where metered REST is expensive, a stream or bulk file (see ais-websocket-stream) may deliver the same coverage at flat cost.

Entries that sit next to Credit-Based API Metering in this glossary:

• ais-websocket-stream
• cc-by-nc