Sandbox links

Your app, its bundle ID and its package stay the same in testing; only the backend that creates links changes. A sandbox API key lets that backend, and your test builds, create links Deep Blue Links tells apart from live ones.

Sandbox keys

An app can have a sandbox key next to its live key. It starts with sandbox_, so a configuration file shows which kind it holds. You generate it on the app's page, and generating it again replaces only the sandbox key, so rotating it never breaks your live servers.

Sandbox links

Every link a sandbox key creates is a sandbox link. Otherwise it's an ordinary link:

• It has the same kind of URLs, on your link host or your custom domains, and opens your app the same way.
• It counts toward your plan's monthly links.
• Its preview page shows a "Sandbox link" banner.

Every API response about a sandbox link carries isSandbox: true: creating it, GET /api/links/{id}, resolve and check-deferred. Responses about live links leave the field out, so your app can test for it:

{ "id": 1001, "longUrl": "https://demo.dev.thedbl.ink/products/1234", "shortUrl": "https://demo.dev.thedbl.ink/Xy3kP9aQ", "isSandbox": true }

When isSandbox is true, load the destination's content from your sandbox backend.

Which key does what

• Any key of the app opens both kinds of link. Your test and release builds share the app and its link host, so a release build that opens a sandbox link still resolves it; the flag tells it apart.
• A sandbox key changes only sandbox links. Updating or deleting a live link with it answers 404, so a sandbox key that leaks from a test build can't alter your live links.
• A live key and the dashboard change both kinds. Sending isSandbox: true with a live key answers 400.

A typical setup

• Your production backend and release builds use the live key.
• Your sandbox backend, debug builds and QA builds use the sandbox key.
• Your app checks isSandbox on every resolved link and loads the content from the matching backend.