Destination SDK Failing because of invalid Auth token(Authencation Failed) | Community
Skip to main content
Level 2
June 15, 2026
Question

Destination SDK Failing because of invalid Auth token(Authencation Failed)

  • June 15, 2026
  • 17 replies
  • 176 views

we are trying to create a destination sdk to swoogo faccing issue which authentication type to use had tried OAuth 2 with Client Credentials Grant it is not working please suggest what kind of customerauthentication to be used for these destination .
below for swoogo request api token for refernce :
https://swoogo.readme.io/reference/post_oauth2-token
Swoogo Api:
https://swoogo.readme.io/reference/updatecontact
these was used in our config json it was not working:

 "customerAuthenticationConfigurations": [

   {

      "authType": "OAUTH2",

      "grant": "OAUTH2_CLIENT_CREDENTIALS",

      "accessTokenUrl": "https://api.swoogo.com/api/v1/oauth2/token",

      "clientId": "XXXXX",

      "clientSecret": "XXXXXXXXXXXXXX",

      "options": {

        "useBasicAuth": true

      }

    }  

  ],

17 replies

RrffggAuthor
Level 2
June 19, 2026

Hi ​@DineshK 
Thanks for reply but is there way to send segment name instead of segment id because segmentid  not helps much to identitfy which profiles belong to which segment in sfmc .
and also why to add feilds schemaConfig.profileFields: here as these from backend automatically will  ingest input.aggregationKey.segmentId  because of these 
if we add here schemaConfig.profileFields that feilds comes up in right side  mapping ui but what we should map from left side .

DineshK
Level 3
June 19, 2026

Two good points you raised.

Sending segment name instead of segment ID

Yes you can. Update your server template request body with this:

 

"requestBody": {
"templatingStrategy": "PEBBLE_V1",
"value": "{\n \"items\": [\n {% for profile in input.profiles %}\n {\n \"firstname\": \"{{ profile.attributes.firstname }}\",\n \"lastname\": \"{{ profile.attributes.lastname }}\",\n \"emailaddress\": \"{{ profile.attributes.emailaddress }}\",\n \"segmentName\": \"{{ destination.namespaceSegmentNames[input.aggregationKey.segmentNamespace][input.aggregationKey.segmentId] }}\",\n \"segmentStatus\": \"{{ input.aggregationKey.segmentStatus }}\"\n }{% if not loop.last %},{% endif %}\n {% endfor %}\n ]\n}"
}

The SDK automatically resolves the actual segment name from AEP at runtime — so whatever you've named your segment in AEP, that's exactly what lands in SFMC. No hardcoding needed. segmentStatus will tell you whether the profile entered (realized) or left (exited) the segment, which is useful for suppression logic in SFMC.

Before testing — make sure your SFMC Data Extension has these two columns added:

  • segmentName (Text)
  • segmentStatus (Text)

If those columns don't exist in the DE, the values will be silently dropped and you won't see any error.

On your schemaConfig.profileFields question — you're right, you don't need to add anything there

profileFields is only for profile attributes that need to show up in the AEP mapping UI — like firstname, lastname, emailaddress where you're manually mapping an AEP attribute to a destination field.

segmentName and segmentStatus are resolved automatically by the SDK from the aggregation context at export time. They don't come from the profile, they come from the segment itself — so there's nothing to map and nothing to add to profileFields. Your aggregation config already has includeSegmentId: true and includeSegmentStatus: true which is all that's needed for these variables to work.

Just update the server template and add the two columns in SFMC. 

Let me know how it goes. 

RrffggAuthor
Level 2
June 19, 2026

 Hi ​@DineshK 
segement name is ingesting to sfmc thanks for your suggestion .
 I had one more question we are using sftp to send the files csv to sftp location in that in mapping to get segment name for profiles can we use caluclate feild there we give something like that which we used in destination sdk .i tried using these error is coming
 

There was a problem preparing mappings.

Bad request parameters or payload. Please check your request and try again. Additional detail: The attribute input.aggregationKey.segmentId does not exist in input schema. Please update the source schema path and try again.The attribute input.aggregationKey.segmentNamespace does not exist in input schema. Please update the source schema path and try again.', The attribute destination.namespaceSegmentNames[v("input.aggregationKey.segmentNamespace")v("input.aggregationKey.segmentId")] does not exist in input schema. Please update the source schema path and try again.',
 

so is these possible here to get segment name for these csv file export what should be there in caluclated feild .please help on these

DineshK
Level 3
June 22, 2026

Hi ​@Rrffgg 

Glad the segment name is working for the SFMC integration.

On the SFTP calculated field question — the error you're seeing is expected and it points to a platform limitation rather than a configuration mistake.

input.aggregationKey.segmentNamespace, input.aggregationKey.segmentId, and destination.namespaceSegmentNames are Destination SDK Pebble template variables. They only work inside a custom destination server httpTemplate — which is what we used for the SFMC integration. These variables are resolved at runtime by the Destination SDK templating engine, which is not available in the file-based destination mapping UI.

The AEP mapping UI for SFTP/CSV destinations works purely against your XDM profile schema. Calculated fields in that context only support XDM path expressions — they have no access to aggregation context variables or the destination.namespaceSegmentNames lookup function. That's exactly what the error is telling you — those paths don't exist in the input schema because they were never part of it to begin with.

This is a current platform limitation for file-based destinations and not something that can be worked around from the mapping UI side.

I'd recommend raising this directly with Adobe Support

--------------
 

If the original Destination SDK authentication issue or the segment name question has been resolved, it would be great if you could mark this thread as answered — helps others in the community who run into the same problem find the solution faster.

It's been a great discussion — good luck with the rest of the implementation!

RrffggAuthor
Level 2
July 8, 2026

Hi ​@DineshK  
Has we disucssed before destination sdk  for sfmc i was able to ingest records when i had use Email identity name space .but i m facing issue when im trying to use custom identity namespace getting identity excluded error can u please let me kmow to do any changes in config json .bprowid is my custom identity namesapce
 

{
"name": "test_Destination_SDK_SFMC_NA_Data",
"description": "insert SFMC Data Extension when segment qualifies",
"status": "TEST",
"customerAuthenticationConfigurations": [
{
"authType": "OAUTH2",
"grant": "OAUTH2_CLIENT_CREDENTIALS",
"accessTokenUrl": "https://mc0fg4tv29db3j89qw46wmj1kdb8.auth.marketingcloudapis.com/v2/token",
"clientId": "l6bpg6jvw3rlgd4a1cc9jlrs",
"clientSecret": "hrjQmMh01BXjQuoPae8KCdne",
"options": {
"useBasicAuth": true
}
}
],
"uiAttributes": {
"connectionType": "Server-to-server",
"category": "personalization",
"monitoringSupported": true,
"flowRunsSupported": true
},
"schemaConfig": {
"profileFields": [
{
"name": "bp_rowid",
"title": "BP Row ID",
"type": "string",
"isRequired": true,
"readOnly": false,
"hidden": false
},
{
"name": "person_id",
"title": "Person ID",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "chubb_id",
"title": "Chubb ID",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "monoline_bop_customerid",
"title": "Monoline BOP Customer ID",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "insured_name",
"title": "Insured Name",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "customerIndustry",
"title": "Customer Industry",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "customersubIndustry",
"title": "Customer Sub Industry",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "first_name",
"title": "First Name",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "last_name",
"title": "Last Name",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "email_address",
"title": "Email Address",
"type": "string",
"isRequired": true,
"readOnly": false,
"hidden": false
},
{
"name": "hashed_email_address",
"title": "hashed Email Address",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "agent_status",
"title": "Agent Status",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "cisa_indicator",
"title": "CISA Indicator",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "phone_number",
"title": "Phone Number",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "mobile_number",
"title": "Mobile Number",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "customer_category_code",
"title": "Customer Category Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "delegation_code",
"title": "Delegation Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "onboarding_date",
"title": "Onboarding Date",
"type": "DATE",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "auth_role_code",
"title": "Auth Role Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "agency_name",
"title": "Agency Name",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "agent_tier",
"title": "Agent Tier",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "agent_role",
"title": "Agent Role",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "pas_code",
"title": "PAS Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "producer_category_code",
"title": "Producer Category Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "product_specialization",
"title": "Product Specialization",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "industry_specialization",
"title": "Industry Specialization",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "branch_name",
"title": "Branch Name",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "branch_location",
"title": "Branch Location",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "branch_region",
"title": "Branch Region",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "branch_code",
"title": "Branch Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "addr1",
"title": "Address 1",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "addr2",
"title": "Address 2",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "city",
"title": "City",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "state",
"title": "State",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
},
{
"name": "postal_code",
"title": "Postal Code",
"type": "string",
"isRequired": false,
"readOnly": false,
"hidden": false
}
],
"profileRequired": true,
"segmentRequired": true,
"identityRequired": true
},
"identityNamespaces": {
"bprowid": {
"acceptsAttributes": true,
"acceptsCustomNamespaces": true,
"acceptedGlobalNamespaces": {}
}
},
"destinationDelivery": [
{
"authenticationRule": "CUSTOMER_AUTHENTICATION",
"destinationServerId": "310a5257-763f-4a6c-9896-aa199f0f95b3"
}
],
"aggregation": {
"aggregationType": "BEST_EFFORT",
"bestEffortAggregation": {
"maxUsersPerRequest": 1000,
"splitUserById": true,
"aggregationKey": {
"includeIdentity": true,
"oneIdentityPerGroup": true,
"includeSegmentId": true,
"includeSegmentStatus": true
}
}
}
}

 

DineshK
Level 3
July 13, 2026

Hi ​@Rrffgg,

The "identity excluded" error with a custom namespace comes down to two things — check them in this order.

 

1. Verify the namespace symbol matches exactly

In your destination config you have:

 

"identityNamespaces": {
"bprowid": { ... }
}

The key bprowid must match the exact symbol of the custom namespace registered in AEP — character for character, including case. Go to AEP → Data Management → Identities, find your custom namespace and copy the symbol directly. If AEP has it as BPROWID or bp_rowid, update the config to match. The SDK match is case-sensitive and a mismatch silently excludes every profile.

 

2. Confirm the profiles in your segment actually carry the bprowid identity

This is the more likely cause. With Email it worked because every profile had Email in their identity map. bprowid is a custom namespace — profiles only carry it if it was explicitly ingested via identity map during data ingestion.

Pick any profile from the segment, go to AEP → Profiles → Identity tab and check whether bprowid appears. If it's not there, the identity was never ingested against those profiles and the Destination SDK has nothing to export — hence excluded.

Your aggregation config has includeIdentity: true and oneIdentityPerGroup: true, which means AEP will only process profiles that carry the bprowid identity. Any profile without it gets dropped at export time.

Fix the ingestion pipeline to include bprowid in the identity map on ingest, re-ingest the data, and re-run the activation. The destination config itself doesn't need changes.

MasonReed11
Level 2
July 12, 2026

You may need to verify the exact OAuth request format Swoogo expects. Test the token call in Postman first and match the same headers/body in your Destination SDK configuration. Also confirm whether useBasicAuth is supported; if not, try sending client credentials in the required format or use a custom auth flow.

Devyendar
Level 7
July 13, 2026

@Rrffgg 

Hi,

For the original Swoogo issue, the Basic Authentication approach is correct.

Swoogo requires the consumer key and secret in the `Authorization: Basic ...` header. Therefore, the Destination SDK OAuth2 client-credentials configuration should contain:

```json
"options": {
  "useBasicAuth": true
}
```

This must be placed inside the OAuth2 authentication configuration’s `options` object. The token request also needs:

```http
POST https://api.swoogo.com/api/v1/oauth2/token
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Authorization: Basic <encoded-consumer-key-and-secret>

grant_type=client_credentials
```

This matches both the Adobe Destination SDK and Swoogo documentation.

However, I do not see confirmation in this thread that the Swoogo connection ultimately succeeded. Could you confirm whether Adobe Support resolved it? If it is still failing, the actual outbound token request should be checked to ensure the Basic Authorization header, content type and form-encoded body are being sent exactly as Swoogo requires.

The later SFMC integration appears to be a separate issue, were you able to get the SegmentName in your SFMC Data extension by using destination.namespaceSegmentNames[input.aggregationKey.segmentNamespace][input.aggregationKey.segmentId] ?

Level 2
July 16, 2026

OAUTH2_CLIENT_CREDENTIALS looks like the right auth type for Swoogo. I would first test the token request separately using Postman/cURL to confirm the client ID, secret, grant type, and authentication method. If Swoogo requires credentials in the request body instead of Basic Auth, update the SDK config accordingly. Also verify if any scopes or extra parameters are needed for the token call.

Devyendar
Level 7
July 21, 2026

Agree, in practice testing out the authentication and even data update to destination through Postman APIs is better and once the approach and payload is success, it is easier to port and build in Destination SDK configurations or server settings.