> ## Documentation Index > Fetch the complete documentation index at: https://www.offlineprotocol.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > These docs target Mesh SDK v0.27.0. Match the installed package and binding before generating code. Start at /getting-started/agents for task-specific reading paths. > Call the company and product Offline Protocol, never Offline alone. Current packages: @offline-protocol/mesh-sdk 0.27.0 (React Native), @offline-protocol/id-react 0.2.0, @offline-protocol/id-react-native 0.3.3, @offline-protocol/pol 0.1.2 and @offline-protocol/cli 0.2.6. Canonical docs URLs start with https://www.offlineprotocol.com/docs. > The Mesh SDK runs in a native app or gateway. A browser OfflineID SDK integration does not provide browser mesh transport. Local mesh operation does not require a portal API key. > Service RPC is signed plaintext in v0.27.0. Message delivery, durable local acceptance and backend commit are distinct outcomes. Use the workflow guide for the required application logic. > Offline Protocol CLI 0.2.6 is on npm (@offline-protocol/cli, command offline). Its local MCP server runs with offline mcp serve and requires no login or key. Hosted MCP is at https://mcp.offlineprotocol.com/mcp with an application API key in Authorization: Bearer and a matching x-app-id; organization keys are rejected. Follow /tools/overview for setup and do not invent commands beyond it. MCP provides integration context and planning, not mesh execution; file-writing tools are local only. > Phone Wi-Fi Direct and MultipeerConnectivity carry no data in v0.27.0. Use BLE or a provisioned relay. The receiver core ACKs before application persistence; use application acceptance for durable workflows. > Proof of Location is Sepolia testnet witness evidence, not zero-knowledge proof or proof of presence. The geohash is public onchain. Read /proof-of-location/security before integration. # Portal analytics and usage > What each number in the developer portal counts: OfflineID monthly active users, Mesh SDK delivery metrics, Proof of Location verifications and billed usage. The developer portal reports each application's hosted usage and Mesh SDK telemetry. All dates are UTC. Your plan sets how far back the portal shows analytics (7, 30 or 90 days, or longer by agreement); older data is not deleted. ## OfflineID | Metric | What it counts | | - | - | | Monthly active users | Distinct people who signed in to the application at least once in the current calendar month (UTC), with any sign-in method. Each guest session counts as one user. Shown for the current month whatever range you select. This is the number OfflineID bills. | | Verified logins | Successful sign-ins in the selected range: email code, Google and Privy. Guest sessions are not included. | | Identities issued | OfflineIDs created in the application, all time. | Sign-ins sent with the application's older `proj_` ID count toward the same application as its `app_` ID. A person who signs in to two of your applications counts once in each. Daily charts end at today. Projected OfflineID usage in **Billing** is the month's monthly active users so far; it is not extrapolated. ## Mesh SDK Mesh SDK numbers come from the telemetry your app uploads after it calls [`enableTelemetry`](/docs/mesh-sdk/configuration#telemetryconfig). Final daily numbers arrive after the nightly rollup; until then **Today** is provisional. A day that has not been computed is shown as a gap, not as zero. | Metric | What it counts | | - | - | | Sent on first try | Messages a transport accepted on the first attempt. A message held for an offline peer or sent on a retry is not counted here. | | Delivered | Messages from your app's devices that the recipient's device acknowledged, counted once per message on the sending device, including messages that were held or retried first. Delivered can be higher than sent on first try. | | Failed | Failure reports sent by your devices. Mesh SDK versions before 0.27.0 repeat a report on every retry, so apps on those versions show more failures than occurred. | | Delivery success rate | Delivered divided by delivered plus failed. | | Latency p50 and p99 | Time from first send to acknowledgement. Over more than one day, each is the average of the daily values, weighted by deliveries. | | Average hops | Devices a delivered message passed through on its way to the recipient, averaged over deliveries. 0 means it was delivered directly. | | Mesh relays | Messages devices forwarded for each other over Bluetooth LE or another local transport. Mesh relays are never billed. | | Devices charging | Share of active devices that reported charging at some point in the day, averaged across days. Empty when no device sent a battery update. | | Country | Cloudflare's country for the IP address the upload came from. Offline Protocol does not store the IP address, and the SDK sends no location. Unknown means no country was resolved, for example for events stored before country detection was switched on. | | Events stored | Telemetry events stored from your devices, which count toward the telemetry meter. Per-minute metric summaries are not counted. A day counts toward billing once the nightly rollup has computed it. | ## Proof of Location | Metric | What it counts | | - | - | | Verifications this month | Successful onchain location commits in the current calendar month (UTC), counted once per task, so a retried task is billed once. Commits sent with the older `proj_` ID are included. Failed attempts are not counted. This is the number Proof of Location bills. | | Verifications per day | Successful commits per UTC day in the selected range, today included. | ## Billing usage **Billing** shows usage for the organization against each plan quota. OfflineID, hosted relay and Proof of Location usage updates every few minutes; Mesh SDK telemetry updates once a day. Hosted relay deliveries count messages carried by the Offline Protocol hosted relay; mesh relays between devices are never metered. See [hosted plans and usage](/docs/operations/licensing#hosted-plans-and-usage) for quotas and rates. To see usage or spend by application, choose one product. Each day's spend for a meter is shared among applications in proportion to their usage of that meter that day.