In navolging van mijn eerdere artikel over Destination SDK heb ik besloten een verdiepend stuk te schrijven dat praktische inzichten geeft. Over Adobe Experience Platform (AEP) Destination SDK wordt veel geschreven, maar de meeste artikelen blijven hangen in configuratieschermen, JSON-snippets en de belofte dat je ‘in principe elk endpoint kunt ontsluiten’. Dat klopt. Maar het wordt pas waardevol als je de volledige keten end-to-end kunt doorlopen en beheersen.

In dit artikel neem ik je mee door een proof-of-concept waarbij ik niet alleen een private destination heb gebouwd, maar de hele activatieketen heb getest: van het moment dat een event het Edge Network binnenkomt tot aan de webhook die het profiel ontvangt. Ik neem je mee in veel voorkomende misstappen, frustraties en inzichten, met als doel de praktische waarde van Destination SDK concreet te maken.

Om dit proces reproduceerbaar te maken, heb ik een lichte testtool gebouwd: Destination SDK Lab, een Streamlit-app die je lokaal kan draaien. Die tool deel ik graag op verzoek.

Waarom Destination SDK?

Binnen Adobe Experience Platform kom je vroeg of laat op het punt dat je iets wilt dóen met je data. Niet alleen opslaan of analyseren, maar een actie triggeren in een extern systeem. Denk aan een profiel dat een bepaalde segmentstatus krijgt en direct een update moet sturen naar Salesforce, een DSP of een interne API.

Op papier klinkt dat simpel: data aanwezig, use case helder, dus doorsturen. In de praktijk loop je daar verrassend snel vast. Standaardconnectors dekken lang niet alles, en als ze er al zijn, ondersteunen ze vaak net niet het gedrag dat je nodig hebt.

Dan kom je op een kruispunt: óf volledig custom bouwen, óf kiezen voor een flexibele oplossing. Dat is precies waar Destination SDK van waarde wordt, niet als generiek exportmechanisme, maar als een manier om zelf de verbinding te definiëren tussen AEP en het systeem waar je data naartoe wilt sturen.

De use case: wanneer er geen connector is

Een concreet voorbeeld: stel je werkt bij een online kansspelaanbieder die wettelijk verplicht is om personen die zichzelf hebben uitgesloten te weren uit de marketingfunnel. Een van de DSP’s heeft geen native Adobe-connector. De data moet naar een custom suppressie-API.

Je loopt tegen twee problemen aan: de segmentkwalificatie moet realtime worden gesynchroniseerd, en er is geen kant-en-klare (native) connector. Destination SDK is dan de aangewezen oplossing, maar hoe bewijs je dat het werkt zonder een volledige website op te zetten?

Dat is de kern van deze POC. In de praktijk wordt er te snel getest met een volledige front-end: Web SDK, cookies, consent flows, het hele ecosysteem. Voor een proof-of-concept is dat vaak overkill. Je wilt één ding valideren: kwalificeert een profiel correct en komt het op de juiste manier (tijdig binnen) bij het eindpunt?

Setup: wat je minimaal nodig hebt

Voor deze POC heb ik de opzet bewust compact gehouden, geen enterprise-configuratie, alleen het essentiële:

• Sandbox binnen Adobe Experience Platform
• Schema op basis van XDM ExperienceEvent (met identity en web field groups)
• ExperienceEvent dataset (en idealiter ook een profieldataset), beide geactiveerd voor Real-Time Customer Profile en Identity Service
• Datastream met AEP-service geactiveerd en de dataset gekoppeld
• Identity namespaces zoals ECID en Email_LC_SHA256
• Adobe I/O-integratie via de Adobe Developer Console: ORG_ID, CLIENT_ID, CLIENT_SECRET, SANDBOX_NAME

In dit voorbeeld is de datastream het verbindingspunt tussen je Edge API-calls en AEP. Hier stel je in welke dataset events ontvangt, en of je Edge Segmentation en/of Streaming Evaluation activeert. In de praktijk bleek Edge Segmentation op mijn sandbox instabiel.

Licentie en toegangsrechten

Private custom destinations zijn alleen beschikbaar voor klanten met het Real-Time CDP Ultimate-pakket. Partners kunnen toegang krijgen via het Technology Partner Program (ISV’s) of via het Solution Partner Program op Gold- of Platinumniveau. Zorg er ook voor dat je in de Admin Console de rol Destination Authoring hebt.

Edge API simulatie

Je kunt ervoor kiezen een Web SDK-flow simuleren via de Edge Network Server API. Met een curl-call naar het Edge-interact-endpoint injecteer je events alsof ze via de Web SDK binnenkomen, zonder website, zonder front-end.

curl -X POST "https://edge.adobedc.net/ee/v2/interact?dataStreamId=<DATASTREAM_ID>" \
-H "Content-Type: application/json" \
-d '{
    "event": {
        "xdm": {
            "timestamp": "2026-04-16T14:50:00Z",
            "eventType": "web.webpagedetails.pageViews",
            "identityMap": {
                "Email_LC_SHA256": [
                    {
                        "id": "a1b2c3...",
                        "authenticatedState": "authenticated",
                        "primary": true
                    }
                ],
                "ECID": [
                    {
                        "id": "123456...",
                        "authenticatedState": "ambiguous",
                        "primary": false
                    }
                ]
            },
            "web": {
                "webPageDetails": {
                    "name": "poc-test-page",
                    "URL": "https://example.com/test"
                }
            }
        }
    }
}'

De timestamp moet actueel zijn. Zonder recente datum kwalificeert je event niet. Een veelgemaakte fout is ook het verwarren van streaming inlets met de Edge-interact-endpoint, dat zijn twee verschillende ingestiepaden.

De payload: klein, maar bewust

Het doel was niet om perfecte businessdata te simuleren. Het doel was om de keten te bewijzen. Daarom is de payload bewust eenvoudig gehouden, maar wel rijk genoeg om stitching en segmentatie te laten werken.

Een representatief voorbeeld ziet er zo uit:

{
  "url": "https://edge.adobedc.net/ee/v2/interact?dataStreamId=e99efb03-63d8-4aa1-bdb5-676e7c873ac4",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "event": {
      "xdm": {
        "timestamp": "2026-04-17T21:02:01.871Z",
        "@id": "c3bec6e8-22b0-4505-afa3-2c4968033189",
        "eventType": "web.webpagedetails.pageViews",
        "web": {
          "webPageDetails": {
            "name": "poc-test-page",
            "URL": "https://example.com/poc-test-page",
            "pageViews": {
              "value": 1
            }
          }
        },
        "identityMap": {
          "Email_LC_SHA256": [
            {
              "id": "63d885f73a891049002005c9aee95894a7feebb219a8bf4aca0c8a91133f1fcd",
              "authenticatedState": "authenticated",
              "primary": true
            }
          ],
          "ECID": [
            {
              "id": "63604305161667845924488878647712751313",
              "authenticatedState": "ambiguous",
              "primary": false
            }
          ]
        }
      }
    }
  }

}Hier zitten precies de velden in die ertoe doen:

• een actuele timestamp
• een eventType
• een identityMap met twee identities
• een page name die later gebruikt wordt voor segment qualification

De timestamp moet actueel zijn als je streaming of edge-nabije evaluatie wilt. De identityMap is nodig om identities aan elkaar te knopen. En web.webPageDetails.name is in dit geval de trigger voor het testsegment.

Om de workflow te vereenvoudigen kun je een “Edge Simulation” activeren voor je eigen test omgeving, deze optie is beschikbaar in de app: 4 -Test & Simulate. Na het ingeven van het datastream ID kan je een test payload sturen naar de dataset die is ingesteld.

Na de eerste succesvolle responses bleek al snel dat “een 200 terugkrijgen” niet hetzelfde is als “nu zie ik direct mijn data in de UI”.

Daar zat een belangrijk leerpunt. De validatie liep via vier routes:

• dataset activity
• preview dataset
• query service
• identity graph viewer

Controleer of de juiste event dataset daadwerkelijk aan de datastream gekoppeld is. Dat klinkt logisch, maar in de praktijk is dit precies het soort detail waar je kostbare tijd op verliest, vooral als je meerdere datasets en schema’s naast elkaar hebt staan.

Daar kwam nog iets bij: streaming ingestie via Edge gebruikt micro-batching. De UI loopt niet altijd synchroon met wat er technisch al gebeurt. Dus je kunt een geldige response terugkrijgen, terwijl dataset activity of preview nog even achterloopt.

Dat is precies waarom Query Service en Identity Graph zoveel waard zijn in debugging. Een simpele controlequery is dan bijvoorbeeld:

SELECT *, eventType, timestamp FROM explensdemo_experienceeventds
ORDER BY timestamp DESC LIMIT 10

Identity stitching en profielopbouw

Het echte omslagpunt in deze POC was niet het moment waarop een event geaccepteerd werd, maar het moment waarop in de identity graph zichtbaar werd dat ECID en Email_LC_SHA256 daadwerkelijk aan elkaar waren gekoppeld.

Dat was het bewijs dat de flow niet alleen events verwerkte, maar ook echt profielvorming deed. Vanaf dat moment was de keten tot hier bevestigd:

event → dataset → identity stitching → profile

En dat is belangrijker dan het op het eerste gezicht lijkt. Want pas als dat klopt, heeft segmentatie überhaupt zin.

Segment creatie: logisch op papier, uitdagend in praktijk

Voor de segmentregel is bewust iets eenvoudigs gekozen: een eventregel op basis van de page name, bijvoorbeeld:

pageName equals “poc-test-page”

In theorie leek edge evaluation logisch. De events komen via Edge binnen, dus dan wil je ook dat segmentevaluatie daar plaatsvindt. Alleen liep dat in de praktijk stuk op een terugkerende 502 fout vanuit de edge segmentation service.

Dat was geen ingestieprobleem. De data kwam binnen. De identities werden gekoppeld. Het probleem zat echt in de edge segmentation service op deze sandbox:

[
  {
    "type": "https://ns.adobe.com/aep/errors/EXEG-0203-502",
    "status": 502,
    "title": "The service call has failed.",
    "detail": "An error occurred while calling the 'com.adobe.experience_platform.edge_segmentation' service for this request. Try again.",
    "report": {
      "eventIndex": 0
    }
  }

]Dat is een belangrijk leerpunt: edge evaluation is niet automatisch de beste keuze voor een POC. Op papier wel, In een developmentomgeving niet altijd.

Een 502 betekent hier dat de Edge Network de upstream Edge Segmentation service heeft bereikt maar een ongeldige response terugkreeg. Dat kan zijn:

- De service is niet ingeschakeld voor jouw org: de call faalt meteen

- Een tijdelijke storing

De workaround was uiteindelijk simpel en effectief: edge segmentation uitschakelen op de datastream en het segment omzetten naar streaming evaluation. Dat bleek in de praktijk veel betrouwbaarder.

Segment qualification bevestigd

Na die omschakeling werkte het wel. Het profiel kwalificeerde voor het segment en was zichtbaar in de audience profile viewer. Ook was zichtbaar dat het profiel actief was op edge en dat beide identifiers aanwezig waren.

Dat is het payoff moment van de hele test: eventdata leidt niet alleen tot ingestie, maar tot profielopbouw én segment qualification.

Vanaf daar hoef je eigenlijk nog maar één ding te bewijzen: verlaat het profiel ook echt AEP richting je custom destination?

De tool: Destination SDK Lab

Destination SDK Lab is een Streamlit-app die je lokaal draait op http://localhost. Geen uitgebreid framework, gewoon een praktische laag bovenop de Destination SDK API’s. De tool begeleidt je door de volledige flow: van het ophalen van een auth token, via het aanmaken van een destination server en config, tot het live inzien van wat er binnenkomt op je endpoint.

Voor het werken met Destination SDK heb je naast een sandbox en de juiste rechten ook de standaard Experience Platform API-credentials nodig: een access token, API key, Org ID en meestal een sandbox name. Deze haal je op via Adobe Developer Console, nadat je als developer bent toegevoegd aan een Experience Platform product profile. Destination SDK zelf is beschikbaar voor Real-Time CDP Ultimate klanten en maakt het mogelijk om private custom destinations te bouwen en via de Experience Platform API’s te beheren, hier wat handige links:

• Authenticatie en headers voor Platform API’s:
• Authenticate and access Experience Platform APIs
• Beginner-vriendelijke versie met Developer Console + Postman:
• Platform API authentication tutorial
• Algemene Experience Platform API-startpagina:
• Getting started with Experience Platform APIs
• Adobe Developer Console:
• Adobe Developer Console

Als je omgevingsvariabelen eenmaal correct zijn ingesteld, doorloop je de hele flow zonder handmatige JSON-constructies of losse Postman-calls. De tool onthoudt de IDs van de objecten die hij aanmaakt en koppelt die automatisch in de volgende stap.

De tool is niet publiek beschikbaar, maar wordt op verzoek gedeeld. Stuur me een bericht als je hem wilt gebruiken.

Installatie

git clone <repo-url>
cd demo/python
pip install -r requirements.txt
streamlit run app.py

De app is bereikbaar op http://localhost:8502.

Benodigdheden

• Python 3.10 of nieuwer
• Toegang tot een AEP-sandbox
• Destination SDK-toegang (Real-Time CDP Ultimate of partnerstatus)
• Adobe Developer Console credentials: ORG_ID, CLIENT_ID, CLIENT_SECRET, SANDBOX_NAME

Stap 1: Omgevingsconfiguratie (Sidebar)

De sidebar is het configuratiepaneel van de tool. Vul hier je AEP-credentials in:

• CLIENT_ID en CLIENT_SECRET — uit je Adobe Developer Console project
• SANDBOX_NAME — de naam van de sandbox (bijv. 'prod' of een dev sandbox)
• BASE_URL en IMS_URL — standaard ingevuld op de Adobe-endpoints, aanpasbaar indien nodig
• DEFAULT_ENDPOINT_URL — het webhook-adres waar AEP deliveries naartoe stuurt

Klik op ‘Save .env Settings’. De sidebar toont ook de Current State van de actieve sessie: inclusief eerder aangemaakte server- en destination-ID’s.

Stap 2: Authenticatie (tabblad Environment / Auth)

Zonder een geldig Bearer token werkt niets. Op dit tabblad klik je op ‘Get IMS Token’. De tool haalt automatisch een access token op en toont hoe lang het nog geldig is. Een token verloopt na ongeveer 24 uur — refresh op tijd, anders volgen 401-fouten in alle volgende stappen. Het tabblad toont ook een Profile Health Check die bevestigt dat je sandbox-verbinding actief is.

Stap Destination Server aanmaken (tabblad Destination Server)

Op dit tabblad definieer je hóé en wáár AEP data verstuurt. De server is de transportlaag:

• Server preset — kies een kant-en-klare configuratie, bijv. ‘ECID + Hashed Email Webhook’
• Server name — geef je server een herkenbare naam
• Endpoint URL — het webhook-adres van je mock of productie-endpoint
• Pebble template — bepaalt welke velden worden meegestuurd in de payload (let op lowercase en dubbele array-diepte, zie sectie over identity mapping)

Klik op ‘Create Destination Server’. Het gegenereerde server-ID wordt automatisch opgeslagen en in de volgende stap gekoppeld.

Stap 4: Destination Config aanmaken (tabblad Destination Config)

Op dit tabblad definieer je wát beschikbaar is in AEP en hoe de destination zich gedraagt in de UI:

• Destination preset — bijv. ‘ECID + Hashed Email Activation’
• Destination name — de naam die zichtbaar wordt in de AEP Destinations catalogus
• Identity namespaces — Email_LC_SHA256 (verplicht), ECID (optioneel)
• Aggregatie en mapping-opties — hoe worden profielen gebundeld in één payload?

Klik op ‘Create Destination Config’. Na een succesvolle aanmaak verschijnt de destination in de AEP Destinations catalogus onder Custom — klaar om te activeren.

Activatie in AEP: van destination naar delivery

Zodra de destination server en config zijn aangemaakt via de tool, verschijnt de destination automatisch in de AEP UI. Vanaf hier verloopt de activatieflow volledig binnen AEP — een wizard van vijf stappen: Configure, Governance, Select audiences, Mapping en Review.

Stap 5: Destination openen in AEP

Navigeer in AEP naar Destinations → Catalog. Je private destination staat onder de sectie Custom. Klik op ‘Set up’ om de activatiewizard te starten.

Stap 6: Configure: verbinding leggen

In de eerste stap van de wizard geef je een accountnaam op en klik je op ‘Connect to destination’. Als de verbinding slaagt verschijnt een groen vinkje naast ‘Connected’. Vervolgens stel je de instancenaam in (bijv. DestSDK_Demo_v9) en bevestig je de endpoint URL.

Stap 7: Select audiences

In deze stap selecteer je welke segmenten je wilt activeren naar deze destination. Voor deze POC heb ik twee audiences geselecteerd: één op basis van batch-evaluatie (ADA-POC Batch, 46 profielen) en één op basis van streaming evaluatie (ADA-POC Streaming, 2 profielen). Het verschil in profielaantal illustreert direct het verschil in evaluatiemethode: batch pikt historische profielen mee, streaming evalueert alleen op nieuwe events.

Stap 8: Mapping: identities koppelen

De mapping-stap is technisch de meest kritische. Hier definieer je welke identity-velden vanuit het profiel worden doorgestuurd naar je destination. In dit geval: IdentityMap: Email_LC_SHA256 → Identity: Email_LC_SHA256.

Let op het verschil: in de AEP UI zie je de namespace als Email_LC_SHA256 (met hoofdletters). In de Pebble-template en de runtime-payload is de key echter email_lc_sha256 (volledig lowercase). Dit is een van de meest voorkomende oorzaken van een stille, lege payload.

Stap 9: Review en activatie

De Review-stap toont een samenvatting: verbindingsstatus, aantal geselecteerde audiences en de mapping. Als alles klopt klik je op ‘Finish’ en is de destination actief.

Na het mappen van de segmenten zal een dataflow run starten, dit is te zien onder destination - View dataflow:

Stap 10: Delivery Viewer: wat komt er binnen?

Nadat de destination actief is, wil je zien of de profielen daadwerkelijk aankomen. De Delivery Viewer toont per binnenkomende batch:

• Tijdstip: wanneer de batch is ontvangen
• Profielcount: hoeveel profielen zijn er in deze batch
• Identifiers: de gehashte e-mail (email_lc_sha256) en ECID per profiel
• Segmentstatus: 'realized' (nieuw gekwalificeerd) of 'exited'
• Full body en headers: de volledige payload inclusief request headers voor debuggen

De statistieken bovenaan geven een snel overzicht: aantal OAuth2-batches, unieke e-mails, webhook-batches, mislukte requests en tijdstippen van de laatste deliveries.

Payload: klein maar bewust

De payload bevat drie elementen die ertoe doen:

• Een actuele timestamp: zonder recente datum kwalificeert er in streaming evaluatie niets (tijdsvenster: 24 uur)
• Een identityMap: minimaal twee identifiers (Email_LC_SHA256 en ECID) zodat identity stitching kan plaatsvinden
• Een eventveld (pageName): het veld dat in de segmentregel wordt gebruikt als kwalificatiecriterium

Een succesvolle delivery in je webhook-log:

{
  "eventType": "audience_qualification",
  "profiles": [
    {
      "ecid": "40162906559973217547089191428526615272",
      "email_lc_sha256": "3f78bda40b1de9d1b98f9c2de074...",
      "segments": [
        {
          "id": "6babb636-...",
          "status": "realized"
        }
      ]
    }
  ],
  "timestamp": "2026-04-16T14:07:29Z"

}

Edge versus streaming evaluatie

De segmentregel in deze POC was simpel: kwalificeer als web.webPageDetails.name gelijk is aan poc-test-page. In theorie lijkt edge evaluation logisch, omdat de events via Edge binnenkomen. In de praktijk gaf de edge segmentation-service op mijn sandbox een terugkerende 502.

Dat was geen ingestieprobleem: de data kwam binnen en identities werden gesticht: maar een service-issue. De workaround: edge evaluation uitzetten op de datastream en overschakelen op streaming evaluation. Daarna kwalificeerde het profiel direct.

Dit verklaart ook het verschil in profielaantallen in de Audiences-stap: de streaming audience kwalificeert alleen op nieuwe events, de batch audience neemt ook historische records mee. Zie ook audience evaluation methods

Identity stitching en mapping: het subtiele probleem

Dit was het meest tijdrovende onderdeel. De mapping van identities naar de webhook leek triviaal. In de praktijk bleek de runtime-structuur anders dan de documentatie doet vermoeden.

Lowercase namespaces: in de payload heten de keys email_lc_sha256 en ecid, niet de variant met hoofdletters zoals in de AEP UI.

De correcte Pebble-template:

{{ profile.identityMap.email_lc_sha256[0].id | default('') }}

Als je de casing of de array-index mist, blijft het identity-veld stilletjes leeg. Er verschijnt geen foutmelding; de webhook ontvangt simpelweg een lege identifier. Dit is precies het soort detail waar je uren op kunt verliezen.

Destination SDK: server versus config

Destination SDK bestaat uit twee bouwstenen die regelmatig worden verward:

• Destination server: bepaalt hóé en wáár AEP de data aflevert: endpoint, HTTP-methode, content-type en Pebble-template.
• Destination config: bepaalt wát beschikbaar is en hoe de destination zich in AEP gedraagt: identity namespaces, mapping- en aggregatieregels, en UI-presentatie.

De tool maakt beide objecten afzonderlijk aan en koppelt ze automatisch. In deze POC gebruikte ik een URL-gebaseerde server met een simpele webhook, bewust zonder authenticatie. Eerst de transportlaag bewijzen, daarna pas auth toevoegen.

OAuth-uitbreiding: authenticated destinations

Nadat de basisflow werkte, ben ik een stap verder gegaan. In productie wil je niet naar een anonieme webhook pushen. Ik heb een mock OAuth2-service gebouwd:

• Token-endpoint (/oauth/token): accepteert client_id, client_secret en grant_type=client_credentials, geeft een dummy token terug
• Beschermd endpoint (/api/endpoint): vereist Authorization: Bearer <token>, stuurt 401 bij een ongeldig token en logt de payload
• Logging: alle requests worden gelogd met timestamp, headers en body

Ook voor deze setup kan je gebruik maken van de preset in onder Step 2 - Destination Server in de Streamlit-app:

Figuur 12: Kies preset "ECID + Hashed Email OAuth2"

Onderstaande server template kan je gebruiken voor deze configuratie:

{
  "name": "Dynamic Endpoint Server (OAuth2)",
  "destinationServerType": "URL_BASED",
  "urlBasedDestination": {
    "url": {
      "templatingStrategy": "PEBBLE_V1",
      "value": "{{customerData.endpointUrl}}"
    },
    "splitUserById": false
  },
  "httpTemplate": {
    "requestBody": {
      "templatingStrategy": "PEBBLE_V1",
      "value": "{\"timestamp\":\"{{ now() }}\",\"eventType\":\"audience_qualification\",\"profiles\":[{% for profile in input.profiles %}{\"email_lc_sha256\":\"{{ profile.identityMap.email_lc_sha256[0].id | default('') }}\",\"segments\":[{% for segment in profile.segmentMembership.ups %}{\"id\":\"{{ segment.key }}\",\"status\":\"{{ segment.value.status }}\"}{% if not loop.last %},{% endif %}{% endfor %}]}{% if not loop.last %},{% endif %}{% endfor %}]}"
    },
    "httpMethod": "POST",
    "contentType": "application/json",
    "headers": []
  },
  "qos": {
    "name": "freeform"
  }

}De setup kan je vinden onder Step 3 - Destination Config in de Streamlit-app.

Figuur 13: Voor het opzetten van een OAuth, kies "ECID + Hashed Email OAuth2 Connect" destination preset

Voor dit voorbeeld heb ik het volgende destination preset template gebruikt:

{
  "name": "ECID + Hashed Email OAuth2 Demo",
  "status": "TEST",
  "customerAuthenticationConfigurations": [
    {
      "authType": "OAUTH2",
      "grant": "OAUTH2_AUTHORIZATION_CODE",
      "accessTokenUrl": "https://bbartholomeus.com/lab/mock/php/oauth-demo/token.php",
      "authorizationUrl": "https://bbartholomeus.com/lab/mock/php/oauth-demo/authorize.php",
      "scope": [],
      "refreshTokenUrl": "https://bbartholomeus.com/lab/mock/php/oauth-demo/token.php",
      "clientId": "demo-client-id",
      "clientSecret": "https://va7prod1activationakv.vault.azure.net/secrets/<clientsecret reference"
    }
  ],
  "customerDataFields": [
    {
      "name": "endpointUrl",
      "title": "Endpoint URL",
      "description": "HTTPS endpoint AEP calls",
      "type": "string",
      "isRequired": true,
      "readOnly": false,
      "hidden": false
    }
  ],
  "uiAttributes": {
    "documentationLink": "https://experienceleague.adobe.com/docs/experience-platform/destinations/destination-sdk/overview.html",
    "connectionType": "Server-to-server",
    "frequency": "Streaming",
    "monitoringSupported": true,
    "flowRunsSupported": true
  },
  "identityNamespaces": {
    "Email_LC_SHA256": {
      "required": true,
      "acceptsAttributes": false,
      "acceptsCustomNamespaces": false,
      "acceptedGlobalNamespaces": {
        "Email_LC_SHA256": {}
      }
    },
    "ECID": {
      "required": false,
      "acceptsAttributes": false,
      "acceptsCustomNamespaces": false,
      "acceptedGlobalNamespaces": {
        "ECID": {}
      }
    }
  },
  "segmentMappingConfig": {
    "mapExperiencePlatformSegmentName": true,
    "mapExperiencePlatformSegmentId": true,
    "mapUserInput": false
  },
  "aggregation": {
    "aggregationType": "BEST_EFFORT",
    "bestEffortAggregation": {
      "maxUsersPerRequest": 100,
      "splitUserById": false
    }
  },
  "destinationDelivery": [
    {
      "authenticationRule": "CUSTOMER_AUTHENTICATION",
      "destinationServerId": "a78cfda0-e552-4855-b27e-8326481a3860"
    }
  ],
  "inputSchemaId": "d03c041f1d21460ba9ef5448823850be",
  "schemaConfig": {
    "profileFields": [],
    "useCustomerSchemaForAttributeMapping": false,
    "requiredMappingsOnly": false,
    "profileRequired": false,
    "segmentRequired": true,
    "identityRequired": true
  },
  "maxProfileAttributes": 9000,
  "maxIdentityAttributes": 1000,
  "destConfigId": "aec47886-5756-4320-8752-29980cdf28cb",
  "backfillHistoricalProfileData": false

}

Figuur 14: Connect met OAuth endpoint in het gegeven voorbeeld

Sample endpoint URL for previews

Met deze mock kun je authenticated destinations testen zonder externe afhankelijkheden. AEP haalt een token op, injecteert het in de header en levert het profiel af bij het beschermde endpoint.

Validatie: hoe weet je dat het werkt?

De grootste valkuil in AEP is het gevoel van valse zekerheid. Ik valideerde via vier routes:

• Dataset activity: geeft een indicatie dat events landen, maar loopt soms achter
• Preview dataset: nuttig voor kleine aantallen
• Query Service: hiermee kun je exact zien welke records zijn opgeslagen en of de identities correct zijn
• Identity graph viewer: wanneer ECID en Email_LC_SHA256 aan elkaar worden gekoppeld, weet je dat profile stitching werkt

Pas als event, dataset, identity stitching en profiel kloppen, heeft segmentatie zin. Controleer altijd in deze volgorde.

Veelgemaakte fouten en hoe je ze voorkomt

• Lowercase namespaces — de documentatie gebruikt Email_LC_SHA256, de runtime-payload levert email_lc_sha256.
• Dubbel geneste arrays — identityMap.email_lc_sha256[0][0] — ga er niet vanuit dat [0].id volstaat.
• Silent failures — AEP geeft geen fout als een mapping leeg is. Je ziet het pas in je webhook.
• False positives — een 200-response op je Edge-call betekent niet dat het segment kwalificeert.
• Status TEST vs PUBLISHED — beïnvloedt alleen de UI, de delivery werkt hetzelfde.
• Verlopen tijdstempel — de timestamp moet actueel zijn (binnen 24 uur).

Toepassingen buiten marketing

Destination SDK biedt uitkomst overal waar je realtime of near-realtime profielbeslissingen naar een extern systeem wilt sturen en Adobe geen standaardconnector biedt:

• Suppressie-flows voor juridische compliance
• Custom DSP-integraties zonder native connector
• Interne activatie-API’s voor callcenters of CRM-systemen
• Real-time fraudedetectie
• Data clean rooms
• Debugging endpoints om payloads te inspecteren tijdens ontwikkeling

Lessons learned

• Je hebt geen volledige website nodig. Een Edge Network Server API-call volstaat om events te simuleren.
• Identity mapping is subtiel. Lowercase keys en juist gebruik arrays zijn essentieel. Één foutje leidt tot een lege payload zonder foutmelding.
• Edge evaluation is niet altijd stabiel. Streaming evaluatie is in een POC-context betrouwbaarder.
• Destination SDK draait om contractdefinitie. Authenticatie, identifiers, payloadstructuur en deliveryregels: niet om een generieke eventbus.
• Test nooit alleen op een 200-response. Gebruik Query Service en de identity graph om te kijken of de data ook land.
• Mock auth is voldoende voor een POC. Je hoeft geen echte OAuth-provider te gebruiken om het mechanisme te begrijpen en testen.

Wil je dit zelf uitproberen?

Als je deze setup zelf wilt reproduceren of een vergelijkbare integratie wilt bouwen, help ik je graag verder.

De Destination SDK Lab tool is niet publiek beschikbaar, maar wordt op verzoek gedeeld. Als je je omgevingsvariabelen correct instelt, doorloop je de volledige flow, van auth token tot live webhook, zonder omslachtige handmatige tussenstappen. Dit is geen verkoopverhaal, maar een uitnodiging om de waarde van Destination SDK praktisch te ervaren.

Stuur me een bericht en we kijken samen wat voor jou zinvol is.

Vooruitblik

In deze POC lag de focus bewust op de basis: transport, stitching, qualification en delivery. De volgende stap is interessanter: authenticatie verder automatiseren en het endpoint realistischer maken.

Daarmee kun je bijvoorbeeld laten zien:

• hoe customer authentication in Destination SDK verder wordt ingericht

• hoe je een fake of echte authenticated endpoint opzet

• hoe je de testflow verder automatiseert met Python CLI en Streamlit

• hoe je een DSP-achtig endpoint simuleert met vendor-specifieke identifiers en payloadcontracten

Dat is de logische vervolgstap. Maar eerst moest de basis kloppen. En dat doet hij nu.

Samenvatting

De belangrijkste conclusie is simpel:

Je hebt geen volledige website met Adobe Web SDK nodig om een Destination SDK integratie end-to-end te testen.

Met een slimme combinatie van:

• Edge Network Server API

• een correct ingerichte datastream

• identity stitching

• streaming segment evaluation

• een private Destination SDK destination

• en een simpel webhook endpoint

kun je de volledige keten bewijzen in een reproduceerbare POC.

Wat deze POC vooral laat zien, is dat het bouwen van een destination niet het moeilijke deel is.

Het moeilijke deel is begrijpen hoe de onderdelen écht samenwerken en waar de documentatie stopt en de werkelijkheid begint.