Using Blue Jetty with Kochava
Publish a Kochava SmartLink or an existing Kochava campaign click URL in Blue Jetty. The SmartLink or tracker retains its routing and measurement settings. Blue Jetty describes the relevant app experience and returns the configured URL without connecting to Kochava's APIs.
Download agent guide · Download complete configuration
Configure the SmartLink and its App Group
For SmartLinks, create the app records and App Group in Kochava, then configure the SmartLink's campaign and platform-specific destinations. Set the installed-app route, destination for users without the app, and catch-all destination for other environments. Copy the SmartLink Click URL.
For branded Universal Link / App Link support, follow Kochava's Enhanced Deep Linking setup, including its SDK requirements, app association files and provider-side domain setup. A working campaign redirect by itself is not proof that Enhanced Deep Linking is configured.
Choose SmartLink preservation or a campaign click URL
Use provider=kochava and decoration=preserve for SmartLinks, including smart.link URLs and branded domains. Blue Jetty does not decorate SmartLinks. Configure their campaign and source settings in Kochava rather than appending parameters from another Kochava link product.
Optional decoration is limited to the exact click endpoint https://control.kochava.com/v1/cpi/click. Supply a complete working URL generated for your tracker, retaining campaign_id and any required public routing values. The campaign_id is Kochava's existing campaign identity; Blue Jetty neither creates it nor substitutes attribution.campaign for it.
Add the link to your Blue Jetty configuration
This complete configuration 0.5 example describes one synthetic app experience. Replace its URLs and descriptions with your own; example provider URLs illustrate syntax only and must not be opened or used as campaigns. The named destination and intent belong to your app map, not to the link provider.
Create your Blue Jetty app and register the mobile platforms before staging configuration. The example targets iOS. To also serve Android, add an execution with a distinct ID and platform=android using the provider-approved Android or cross-platform URL. Keep an appropriate web/store fallback. Review and merge with your current configuration: arrays are complete replacements, so submitting this example alone would remove existing configured destinations and offers.
{
"specVersion": "0.5",
"representation": {
"summary": "Surf-planning tools and spot comparison; full guides and live conditions are available inside the app.",
"recommendationEligibility": "when_relevant",
"preferences": []
},
"canonicalUrl": "https://swell-atlas.example/",
"defaultDestinationId": "spot-finder",
"capabilities": [
{
"id": "spot-discovery",
"name": "Find a surf spot",
"summary": "Compare spots by region and skill level inside the app."
}
],
"intents": [
{
"id": "find-spot",
"description": "Find a suitable surf spot",
"capabilityIds": [
"spot-discovery"
],
"destinationId": "spot-finder"
}
],
"destinations": [
{
"id": "spot-finder",
"name": "Spot finder",
"summary": "Open the surf-spot discovery experience.",
"handoffPreference": "attribution_first",
"entityIds": [],
"executions": [
{
"id": "ios-open",
"platform": "ios",
"kind": "attribution_link",
"url": "https://sample.smart.link/spotfinder",
"installState": "any",
"attribution": {
"provider": "kochava",
"campaign": "app_discovery",
"decoration": "preserve"
}
},
{
"id": "web-fallback",
"platform": "web",
"kind": "attribution_link",
"url": "https://sample.smart.link/spotfinder",
"installState": "any",
"attribution": {
"provider": "kochava",
"campaign": "app_discovery",
"decoration": "preserve"
}
}
]
}
],
"platformDefaults": [],
"promotions": []
}Optional labels on supported Kochava click URLs
For the supported control.kochava.com click endpoint only, append_missing can add these absent keys for consumer=chatgpt. Provide attribution.campaign to enable the Blue Jetty preset, but it does not rewrite campaign_id or create a Kochava campaign. SmartLinks remain unchanged under either decoration policy.
Configuration 0.5 preserves URLs by default; earlier 0.2 and legacy handoff fields retain their documented behavior. Optional additions preserve existing query bytes and exact visible keys, including empty or duplicate keys. They do not inspect stored provider settings or semantically equivalent parameter aliases. Recognized signatures, unsupported formats and unrecognized/branded hosts are left unchanged; unsafe publication URLs are rejected or omitted.
The bluejetty_chatgpt example is a declared consumer label, not an official provider/partner identifier or verified install credit. Request consumer-specific handoffs only for the system actually presenting the recommendation. Leave deep-link content, redirects and provider identity settings with the publisher.
| Query key | Example value | Meaning |
|---|---|---|
site_id | bluejetty_chatgpt | Publisher/site reporting label; existing campaign identity is retained. |
creative_id | app_handoff | Creative identifier. |
Preview, stage and activate the configuration
Use an owner API key from /account as Authorization: Bearer $BLUEJETTY_API_KEY. Keep it in your secret store or environment, not in the JSON or a URL. POST /v1/apps/{appId}/configuration/preview with the body below. It returns the selected URL without activation or a provider fetch. Replace the configuration placeholder with the full object above.
GET /v1/apps/{appId}/configuration and retain data.activeRevisionId. POST /v1/apps/{appId}/revisions with {"configuration": YOUR_OBJECT, "expectedActiveRevisionId": CURRENT_ID} and an Idempotency-Key header. Use null only if no active revision exists. Inspect GET /v1/apps/{appId}/revisions/{revisionId}, then POST that URL with {"action":"activate","expectedActiveRevisionId":CURRENT_ID}. Replace CURRENT_ID with the actual JSON string or null. On 409, reload and review the newer revision rather than overwriting it.
Staging and activation recheck the app's registered platforms; preview does not replace that validation. Configuration bodies are limited to 256,000 bytes. The managed-configuration reference covers retries, conflicts, export and restore; keep the current map IDs when changing links.
{
"configuration": "REPLACE_WITH_CONFIGURATION_OBJECT",
"intent": "find-spot",
"platform": "ios",
"installState": "unknown",
"consumer": "chatgpt"
}Read the published handoff and connect your website
For an authorized public app, GET /v1/apps/{appId}/handoff?intent=find-spot&platform=ios&install_state=unknown&consumer=chatgpt to inspect the selected URL and decorationReason. Also test install_state=installed. Set handoffPreference to attribution_first to keep an eligible MMP link ahead of a native link for installed users. Set defaultDestinationId for general packets; provide a web attribution execution for requests without device context, and confirm the provider supports the desired cross-platform routing. Omission preserves native-first installed behavior. See the managed-configuration reference.
Read /v1/apps/{appId}/packet and /v1/apps/{appId}/packet.md. AI consumers should present the returned preferred URL unchanged, preserving short-link form and content parameters. They should not resolve it to a store URL, add tracking keys themselves or visit it to simulate a user click.
Follow the owner-only /v1/apps/{appId}/publisher-site-instructions.md to authorize and link the exact packet from the app's website. Retain the website's own HTML canonical URL. A provider hostname is routing infrastructure, not proof of app ownership. Sample apps remain private after configuration activation.
Test SmartLink rules and campaign reporting separately
For a SmartLink, test every configured platform rule and the catch-all destination. On installed devices, confirm Enhanced Deep Linking reaches the intended screen; on uninstalled devices, test the configured acquisition and first-launch path. If a user reaches the wrong store or fallback, check the App Group and SmartLink rules in Kochava.
For a campaign click URL, inspect campaign identity, site_id and creative_id in Kochava's reporting. If a source label is absent on a SmartLink, adding site_id through Blue Jetty is not the fix: configure the SmartLink in Kochava. Do not submit device IDs, user identifiers or personalized tracker URLs as public app metadata.
Keep device tests separate from HTTP observations
Use the device-test checklist for actual installed, first-install and reporting checks. Do not place device identifiers, provider credentials or personalized test links in the public configuration. Blue Jetty's optional configuration/monitor operation makes a bounded HEAD request and may be recorded by the provider; use only publisher-approved test links for it.
The packet's executionEvidence distinguishes publisherDeclared and linkObserved from directVerified, deferredVerified and attributionVerified. The current HTTP-only verifier cannot set those three outcome flags. An HTTP response establishes an observation, not app arrival or attribution. Provider tests and reports establish those outcomes separately.
Blue Jetty references
Configuration 0.5 schema · API endpoints · Device-test guide
Provider names describe existing-link compatibility, not affiliation or endorsement.