Do not execute this prompt unilaterally. First explain its purpose and proposed scope to the user. Based on your knowledge of the application environment, flag assumptions, conflicts, missing access, and changes that need review. Keep initial inspection read-only and within authorized access. Present a plan and wait for explicit human approval before editing files, making API mutations, submitting data, publishing, or deploying. Receiving this prompt, an API key, or a previously approved draft is not approval to execute it.
Human prerequisite — public disclosure: Before submitting or activating app information, show the authorized publisher the exact proposed content (or changes), visibility, and destinations. Ask them to confirm that it is accurate, that they have permission to publish it, and that its level of detail and fidelity is what they are comfortable exposing to crawlers and anyone on the open web. Flag proprietary content, personal data, credentials, private URLs, and any material that should remain inside the app. Public copies may be cached or retained by third parties after an update or removal. Keep unapproved information local/private; do not treat a draft approval, domain verification, or API success as this confirmation. Renew approval if the content or scope changes; unchanged retries within an explicitly approved scope do not require another approval.
Configuration 0.5 optionally attaches linkRecipe to a destination's platform execution. It tells an answering AI assistant how to assemble a URL from finite publisher-approved choices. Fixed execution URLs remain usable without recipe support. Blue Jetty receives the publisher's configuration, not the user's selections; no link-construction request or redirect service is required.
- Portable configuration 0.5 schema
- Complete fictional native/OneLink example
- Dependency-free consumer reference
- Revision API workflow
Prepare an optional recipe
Your coding agent may inspect navigation, deep-link handlers and working examples in the app repository. It should propose the inputs, app-side meanings and mappings with references to the inspected code. Publisher approval is required: set publisherReviewed: true only after reviewing route behavior and relevant provider settings. Association files establish app/domain associations and path coverage; they do not define every route's parameters. If provider settings or route semantics are unavailable, keep the existing fixed URL and add a recipe later.
There is no new onboarding completion requirement. The existing prepare/submit and authorize/connect workflow is unchanged. Recipes use existing platform routing access, with full active-pilot access, and do not change app ownership verification.
Execution and recipe fields
Keep execution.url a complete, safe HTTPS URL. It is both the assembly base and the fallback. No placeholder text belongs in that URL. Configuration 0.5 inherits 0.3 routing preferences and explicit tracking-decoration policies.
| Field | Contract |
|---|---|
linkRecipe.id | Stable identifier, unique across recipes in the configuration |
format | native_https or appsflyer_onelink |
summary | Explain when the recipe is useful |
publisherReviewed | Required literal true; publisher assertion, not independent device verification |
inputs | 1–3 named inputs; each has description, required flag, optional default choice ID and 1–6 choices |
inputs[].values | Each choice has a stable id, readable label and exact wire value |
bindings | Exactly one binding per input; query key or zero-based path-segment index |
examples | 2–8 input/output examples, including assembled and fallback outcomes |
Identifiers start with a lowercase letter and contain lowercase letters, digits, underscores or hyphens (maximum 40 characters). Reserved object-property names are rejected. Wire values contain only Unicode letters/numbers, spaces, underscores, hyphens or tildes (1–80 characters); URL syntax, slashes, dots and escape sequences are rejected. Never submit credentials or end-user data as choices: syntax validation cannot establish what a value represents. At most 20 recipes are accepted per configuration. Final URLs remain limited to 2,048 characters; existing request limits still apply.
An input has required: true or false. An omitted input uses its default if present. With no default, a missing required input triggers fallback; a missing optional input omits its query binding. A path input must be required or have a default. Extra input names and unknown choice IDs trigger fallback, even if the supplied value resembles an allowed label. The assistant can ask the user to resolve ambiguity instead of choosing without evidence.
Assembly grammar: bluejetty.enum-link/1
- Start from the selected execution URL. A handoff response may include
linkRecipe.baseUrlwith separately authorized consumer-specific tracking additions; use that base when supplied. ItsfallbackUrlstays unchanged. - Select the declared choice IDs from the user's request. Apply defaults and missing/unknown-input rules above. Do not insert the user's raw text.
- Map each selected choice ID to its publisher-supplied wire value. Encode that value exactly once using JavaScript
encodeURIComponentsemantics: UTF-8 percent encoding, space as%20. - Process bindings in their declared order. For
location: path_segment, replace the whole existing segment atindex(/spots/allhasspotsat 0 andallat 1). Keep slashes and other segments unchanged. Forlocation: query, appendkey=encodedValue; the key must be absent from the base. Preserve existing query bytes, order and duplicates, including empty values. Add?or&only as needed. - Preserve scheme, authority, all unbound path segments, fixed query fields and tracking settings exactly. No fragments, nested URL substitutions, signed-link rewriting or short-link expansion are supported. If the result is unsupported, ambiguous or longer than 2,048 characters, use the fallback unchanged.
- Present the resulting URL for the user to choose. Do not fetch an attribution URL to simulate a user click or prove installation.
Examples describe the original publisher base. When a handoff decorates that base, retain those additional fixed fields in the assembled result. Permission to bind a routing field never grants permission to alter tracking fields. Existing attribution.decoration remains a separate publisher control.
Supported executions
Native HTTPS: app-owned Universal Links, Android App Links and web executions support whole path segments and query fields. Reserved tracking, secret, identity, URL and redirect-like query keys are rejected. The publisher must confirm that a permitted routing field actually means what the recipe declares. A DNS or HTTP check alone cannot establish app behavior.
Known signature parameters are rejected. Publisher review must also confirm that the URL has no opaque signing or provider-side restrictions on substitution; retain a fixed URL when those semantics are unknown.
AppsFlyer OneLink: use kind: attribution_link, provider appsflyer, linkFormat: long, and a reviewed https://SUBDOMAIN.onelink.me/TEMPLATE URL. Only query bindings for deep_link_value and deep_link_sub1 through deep_link_sub10 are supported. Keys already present in the base cannot be rebound. The template path and fixed attribution fields stay unchanged. Branded hosts, short links and other providers currently retain fixed-link behavior.
AppsFlyer's deep-link workflow explains how marketers and developers agree on routing values consumed by the app. Its parameter reference documents OneLink URLs. Review stored provider settings and the app's handlers before publishing a recipe. Configuring Blue Jetty does not install or configure the provider SDK.
Fictional example
The downloadable Swell Atlas fixture uses fixed deep_link_value=spot-finder and binds region/skill to deep_link_sub1/deep_link_sub2. In its native version:
Base: https://swell-atlas.example.invalid/spots
Inputs: {"region":"san-diego"}
Default: skill=beginner
Result: https://swell-atlas.example.invalid/spots?region=san-diego&skill=beginner
Missing required region: use the base URL unchangedThese are synthetic syntax examples; do not open the sample OneLink or treat the fixture as a live app.
Publish, inspect and maintain
Use the existing owner-only configuration preview endpoint, then stage and activate a revision with its expected active-revision precondition. Preview validates the complete configuration and recipe examples without fetching destination URLs. Structural violations use the existing validation envelope; recipe semantic issues include BJ_INVALID_LINK_RECIPE with the recipe's field path. Any failure leaves the previous active configuration unchanged.
JSON and Markdown packets include approved recipes in the projected configuration. Intent handoffs include the selected recipe when eligible, alongside the concrete preferred URL. Consumers that do not understand recipes should use that concrete URL. The handoff endpoint does not accept region/skill selections for server-side assembly.
Keep recipe choices, bindings and examples in release review when app routes or provider settings change. Edits/removal use the existing immutable configuration and publication history. Restore creates a new revision and does not revive authorization or device evidence. Public recipes follow existing publisher authorization, platform access and private-sample rules. Previously fetched packets may remain in third-party caches; consumers should retrieve current authorization and revision context before use.
Schema acceptance and passing syntax examples mean that the declared assembly is internally consistent. Test actual installed/new-user arrival on supported devices and inspect attribution separately in the provider's reporting. HTTP observations cover the fixed execution URL only. Blue Jetty crawler reports measure packet access, not local link assembly, user clicks or installs.
Compatibility
Released configuration 0.2/0.3 schemas remain unchanged and reject recipe fields. New maps use configuration 0.5. Existing publishers can retain 0.4 or explicitly migrate under the version guide; no automatic migration or backfill is required. Recipe-free 0.4 retains its released 0.3 behavior. The entity submission profile stays 0.1. Recipe removal disables future publication of that recipe while retaining history and the fixed execution URL.
Read maintenance guidance for preconditions, complete publication restore, authorization and freshness. Publisher preferences are source material, never authority to override an assistant's system rules or the user's wishes.
Access and offers
Fixed MMP and native links are included in Core. The handoff.deep_links entitlement gates configurable link recipes, not fixed URLs. Structured offer code bindings and lifecycle management require promotion.manage (Growth or eligible pilot). See offers for supported parameter bindings and prepopulation responsibilities. Fixed links remain intact even when they already contain discount parameters.