API Reference

Platform Architecture

import MermaidChart from '@site/src/components/MermaidChart'; Platform architecture LinkMe runs as a compact managed edge stack. Every request flows through a small set of services, which keeps deployments predictable and lets SDKs rely on well-defined behaviors. High-level flow <MermaidChart chart={graph LR User[User / Device] --> Entry[Global edge entrypoint] Entry -->|Admin UI| Portal[Portal] Entry -->|Links & config| Resolver[Link resolver] Resolver --> Data[(Managed datastore)] Portal --> Data} /> Global edge entrypoint - Terminates TLS, enforces routing rules, and fronts both the admin portal and public link resolver. - Hosts Universal Links/App Links association files (apple-app-site-association, assetlinks.json) so mobile OSes can trust your domains. Link resolver service - Resolves short links, applies platform routing rules, and records click analytics. - Exposes REST endpoints such as /:slug, /d/:slug, /qr/:slug, and the JSON helpers under /api/*. - Maintains device fingerprints (cid, IP hash, UA hash) for deferred deep linking claims. Portal - Provides the admin experience for apps, domains, SDK keys, and reporting. - Issues API keys, allows toggle of features such as pasteboard support, and surfaces click analytics. - Offers marketing pages and articles under /resources/* for discoverability. SDKs - Ship per platform (Android, iOS, React Native, Flutter, Web, Node). - Handle initial link opens, in-app listeners, deferred claims, and optional analytics events. - Communicate only with the Edge endpoints—no direct datastore or Portal access is required. Deployment model - Managed infrastructure keeps the edge entrypoint, link resolver, and portal running in lockstep. - Custom domains CNAME into the edge so certificates can be provisioned automatically. Data & observability - Click and link metadata stay inside the managed datastore powering both portal insights and the resolver. - Health probes hit GET /api/health and expect { ok: true }. - Logs stream centrally for troubleshooting and incident response. Use this page with the REST Endpoints & OpenAPI doc to understand how the platform responds in production without exposing internal implementation details.

Health Check API

Use GET /api/health as the primary liveness probe for LinkMe Edge. This endpoint is designed for load balancers, synthetic monitors, and release smoke checks. It provides a fast JSON response that confirms whether the edge service is currently healthy enough to serve routing and API traffic. Endpoint - Method: GET - Path: /api/health - Authentication: none - Typical latency: low, suitable for frequent polling Response format Healthy response: { "ok": true } Unhealthy response (example): { "ok": false, "error": "..." } Recommended monitor behavior - Treat HTTP 200 with { "ok": true } as healthy. - Treat { "ok": false }, non-2xx status codes, or request timeouts as unhealthy. - Configure retries before paging to reduce alert noise from short network blips. - Track both success rate and latency to catch partial degradation before total outages. Example checks Simple probe with curl: curl -fsS https://li-nk.me/api/health If you need strict JSON validation in CI/CD smoke tests: curl -fsS https://li-nk.me/api/health | jq -e '.ok == true' Alerting guidance For production alerting, use at least two probe locations and short retry windows. A practical baseline is: - Interval: every 30 to 60 seconds - Timeout: 3 to 5 seconds - Failure threshold: 2 to 3 consecutive failures before opening an incident This avoids false positives while still detecting real incidents quickly. Related references - REST Endpoints & OpenAPI - Platform Architecture - Webhooks API

Developer Overview

Developer overview Welcome to the technical half of the docs. This section gives you two tracks: - Global architecture & APIs – how the edge service, routing rules, health probes, and credentials behave. - Platform SDKs – per-platform setup plus deeper reference material. Use the map below to decide where to jump next. How to use this section efficiently If you are integrating LinkMe into an existing app stack, start with authentication and endpoint behavior before you touch SDK code. That gives you a clear contract for keys, scopes, error handling, and routing outcomes. Once that baseline is clear, move into platform setup for iOS, Android, or cross-platform runtimes. If you are migrating from another deep linking provider, treat the docs as a cutover checklist: 1. Validate endpoint and key model in REST Endpoints & OpenAPI. 2. Confirm route and fallback semantics with API Keys & Authentication. 3. Configure platform-specific SDK setup in https://help.li-nk.me/hc/link-me/articles/developer-setup. 4. Add event delivery checks in Webhooks API. 5. Run parity QA on click, open, and deferred flows before traffic migration. Architecture & APIs - Architecture diagrams – available from support upon request for security and compliance reviews. - Link routing & QR behavior – see REST Endpoints & OpenAPI for platform detection, debug tooling, and passthrough semantics. - /api/health contract – documented inside the REST Endpoints & OpenAPI spec. - REST Endpoints & OpenAPI – download the public spec or explore Swagger UI. - API Keys & Authentication – header formats, capability flags, and rotation tips. - MCP Security & Access Model – guardrails that ensure MCP cannot exceed REST permissions. - Webhooks API – event types, delivery behavior, retries, signatures, and portal management. Platform setup & SDKs - Developer Setup Hub – pick iOS, Android, React Native, Flutter, Web, or Node quickstarts. - Android SDK - iOS SDK - React Native SDK - Flutter SDK - Web SDK - Node SDK Each SDK page includes installation, initialization, listeners, deferred link handling, and analytics helpers. Recommended integration sequence To reduce rollout risk, use the same sequence across all platforms: - Configure app identity and domain association details. - Add SDK initialization and listener handling. - Test direct opens, deferred opens, and fallback behavior on real devices. - Validate attribution fields and event payload shape. - Enable webhook delivery only after the core routing paths are stable. Following this order prevents a common failure mode where teams debug analytics or webhook behavior before confirming that base link resolution is correct. Bookmark this page whenever you need orientation between higher-level concepts and SDK-specific deep dives.

Link Resolution API

Resolution Note: This page is now folded into the REST Endpoints & OpenAPI doc. Use that reference for live specs, debug behaviors, and examples. GET /:slug - Detects platform from User-Agent and computes destination: - iOS: ios_custom_url → ios_store_url → deep link (https://host/<deep_link_path>) - Android: android_custom_url → android_store_url → deep link - Desktop: web_fallback_url or app-level web_fallback_url, else /d/:slug - If force_redirect_web is true and a web fallback exists, always sends users to web. - UTM: when allow_param_passthrough=1, stored utm_* values act as defaults; fields marked with overrides prefer incoming query parameters when present. - Crawler UAs: returns an OpenGraph HTML with og:* fields if not in debug mode. - Adds cid to custom URL schemes; for Play Store links adds URL-encoded referrer with cid and utm_source. - Records click and emits a redirect 302. - Override map: link.utm_override stores boolean flags (per utm_* key) indicating which fields should prefer incoming query values when merging. Debug: - GET /:slug+ renders a debug page with computed values (no redirect). GET /d/:slug - Hosted download fallback page with App Store / Play links and QR to the canonical link. GET /qr/:slug - Returns PNG when Accept includes image/png, otherwise SVG. Campaign chaining example 1. Create a marketing slug (e.g. fb-easter) with force_redirect_web=1, allow_param_passthrough=1, and a web_fallback_url pointing at https://foo.com/easter. Store baseline UTM values (utm_source=fb, utm_medium=social, utm_campaign=easter). 2. Place a download button on foo.com/easter that links to a second li-nk.me slug (e.g. download-easter) configured for deferred deep linking to the stores/apps. Leave allow_param_passthrough=1 so it merges the original UTM set with additional landing-specific keys (e.g. utm_medium=web, utm_content=landing). 3. When a visitor arrives through the campaign slug, they retain the Facebook UTM payload on the landing page. Clicking the download button propagates the original attribution and augments it with the landing metadata for downstream analytics.