Deep Links Without an SDK: everything via API

Overview

The REST-only approach is ideal if you avoid third-party binaries, have strict size budgets, or prefer explicit control over networking. SDDL issues a unique key for every link and stores the metadata you attach (e.g., product_id, coupon, partner_id, utm_source). When your app launches, it calls the API to resolve that key and decides where to route the user—cart, paywall, onboarding step, promo screen, or any custom destination. No SDK required.

When does a no-SDK integration make sense?

• Strict app footprint: you minimize dependencies and binary size.
• Compliance or review constraints: easier audits, fewer third-party updates.
• Custom networking stack: you already have a thin wrapper for HTTP calls.
• Server-side control: your backend orchestrates routing and payload validation.

You can always adopt SDDL SDKs later for convenience; the REST API remains the same.

How the REST flow works

1. Create a link in SDDL and attach metadata + UTM.
2. User clicks the link from ads, email, SMS, social, or QR.
3. If the app isn’t installed, SDDL redirects to the store and keeps the context.
4. On first launch, your app resolves the payload via:
   • GET /api/{key}/details — when you know the key (extracted from the link).
   • GET /api/try/details — fallback when the key is unknown.
   • Clipboard fallback: if no URL was delivered, your app can read the key from the system clipboard (when present) and try /api/{key}/details before calling /api/try/details. This best-effort step increases restore accuracy on cold start.
5. Your app opens the correct screen and applies the metadata (e.g., coupon).

Implementation details (no SDK)

Your app needs two simple capabilities: extract a key from the incoming Universal Link/App Link when available, and perform a GET request on launch to resolve the context. For maintainability, keep the logic inside a small helper that you can test independently.

You do not need to host verification files. SDDL automatically publishes apple-app-site-association (iOS) and assetlinks.json (Android) from your app settings. Use your custom domain for brand trust, or a subdomain on sddl.me.

Need platform setup guidance? Follow the step-by-step guides for iOS Universal Links and Android App Links, plus the Deferred Deep Links overview.

Security & privacy

SDDL is designed to keep context without invasive tracking. You control which fields to store in link metadata. To reduce abuse, detail records are marked as used after your app reads them, and you can validate payloads server-side before granting value (e.g., coupons or inventory). Use custom domains and HTTPS to reinforce brand trust.

Setup requirements

• iOS Universal Links: add the Associated Domains entitlement and include your SDDL domain.
• Android App Links: declare verified links in your manifest; SDDL serves assetlinks.json.
• Optional interstitial: enable the intermediate page for the most reliable deferred flow.

Use our Testing & QA Playbook to verify end-to-end before scaling campaigns.

Best practices

• Use the clipboard fallback first: on cold start, try to read the key from the system clipboard and call /api/{key}/details; if no key is present, call /api/try/details.
• Keep metadata concise: include only what you need for routing and personalization.
• Standardize UTM: align naming across ads, email and partner links.
• Validate server-side: confirm eligibility before redeeming value.
• Use a custom domain: improves deliverability and reduces false positives in clients.

FAQ