Adobe campaign

Update The Wallet Crew passes from Adobe Campaign Classic workflows by calling The Wallet Crew API.

Adobe Campaign (Classic)

Adobe Campaign workflows can trigger The Wallet Crew API calls. This enables automated pass updates during a campaign. Typical updates include adding an offer, updating loyalty data, or writing a campaign message into additionalData.

Real-world examples

• A retail brand adds a personalized message to a VIP segment pass, right after send-out.
• A show organizer updates a wallet ticket with a last-minute gate change.
• A ticketing provider writes a campaignId into additionalData to measure wallet conversions.

Prerequisites

Access to an API key with permission to update passes is required. A stable identifier must also exist in Adobe Campaign, and match the identifier used to find passes in The Wallet Crew (for example, a customer ID).

The API host and path depend on the environment (QA vs production) and The Wallet Crew project setup. Sample URL values must be replaced with the ones provided by The Wallet Crew.

API request overview

The Wallet Crew pass update API is called with PATCH. The example below filters passes using a project-specific identifier (id.y2.customerId) and updates additionalData.

Example PATCH request

curl -X 'PATCH' \
  'https://app-qa.neostore.cloud/api/xxxxx/passes?id.y2.customerId=00100000207298' \
  -H 'accept: */*' \
  -H 'X-API-KEY: xyz' \
  -H 'Content-Type: application/json' \
  -d '{
        "additionalData": {
          "adobe_message": "Exclusive offer: come visit us."
        }
      }'

Adobe Campaign workflow design

The safest setup keeps selection and execution separate. Selection defines who should be updated. Execution defines what should be written to the pass.

1

Select the audience

A query activity selects the target population. The outbound transition should contain the identifier that matches The Wallet Crew pass lookup key (example: customerId).

2

Iterate on records

A workflow pattern can process one record at a time, or small batches, depending on the expected volume. This reduces the blast radius in case of API errors.

3

Call The Wallet Crew API

The PATCH /passes endpoint is called for each identifier. The payload should stay minimal and only write fields that must change (example: additionalData.adobe_message).

4

Log and handle errors

Workflow logs should store the HTTP status code and response body. An explicit error path for non-2xx responses is recommended (retry, quarantine, or manual review), depending on campaign criticality.

5

Validate results

Validation typically starts with a small test segment. Expected fields can then be confirmed on a sample of passes in The Wallet Crew.

Implementation example (JavaScript activity)

This section provides an example for an Adobe Campaign Classic JavaScript activity that updates passes in The Wallet Crew for a selected population.

Needs confirmation: the exact APIs available in JavaScript activities vary by Adobe Campaign version and hosting model. The snippet below is an implementation example and may require adaptation for the instance (query method, HTTP client, credential storage).

Example JavaScript activity (illustrative)

// The Wallet Crew API configuration
var apiUrl = "https://app-qa.neostore.cloud/api/xxxxx/passes";
var apiKey = "xyz"; // API keys should be stored as secrets, not hardcoded.

// Fetch the list of customers from the workflow context (adapt to the instance data model)
var query = xtk.queryDef.create();
query.select("customerId")        // Identifier field used to find passes
     .from("customerTable");      // Source table
var customers = query.executeQuery();

for (var i = 0; i < customers.length; i++) {
  var customerId = customers[i].customerId;

  // Construct the API endpoint URL
  var url = apiUrl + "?id.y2.customerId=" + encodeURIComponent(customerId);

  // Define the payload for the API request
  var payload = {
    additionalData: {
      adobe_message: "Exclusive offer: come visit us."
    }
  };

  try {
    // Execute the API call (adapt the HTTP client to the instance capabilities)
    var response = http.request({
      method: "PATCH",
      url: url,
      headers: {
        "X-API-KEY": apiKey,
        "Content-Type": "application/json",
        "accept": "*/*"
      },
      body: JSON.stringify(payload)
    });

    logInfo("Customer ID " + customerId + ": update OK. Status: " + response.statusCode);
  } catch (error) {
    logError("Customer ID " + customerId + ": update failed. Error: " + error.message);
  }
}

Best practices

Testing on a non-production environment reduces risk. Error handling should be explicit, because API failures can be transient. If rate limiting is enabled on the project, throttling or batching helps avoid 429 responses. API keys should be treated as secrets and stored using Adobe Campaign’s secure options, when available.

FAQ

What should be used as the identifier in the API filter?

The identifier should match what was configured in The Wallet Crew project for pass search. Common identifiers include a customer ID, loyalty ID, or an external user ID. The query parameter name (example: id.y2.customerId) depends on the project data model.

How to confirm that passes were updated successfully?

Confirmation usually requires both workflow logs and spot checks in The Wallet Crew. Workflow logs should keep the request identifier and the HTTP response. Spot checks should verify the expected fields (example: additionalData) on a small sample of passes.

How to avoid rate limits when updating large audiences?

Batching and throttling reduce the chance of hitting API limits. A common approach is to process records in small groups, add pauses between batches, and retry with backoff on 429/5xx responses.

Where should the API key be stored in Adobe Campaign?

API keys should be handled as secrets. Prefer Adobe Campaign mechanisms meant for credentials storage, rather than hardcoding values in activities or scripts. Access should be restricted to the minimum set of operators and workflows.