An Adobe Experience Platform audience can identify a useful customer moment, but your organization still needs to decide whether a gift is appropriate, authorized and safe to send. This blueprint proposes a custom integration with Giftpack through a controlled adapter. It is an implementation design, not evidence of a native connector or a deployed customer integration.
Decide the responsibility boundary before the connection
Start by assigning three different records of truth. Experience Platform owns the customer signals and audience evaluation used in this workflow. Your adapter owns the decision to execute a particular gifting opportunity, including its policy version and budget reservation. The fulfillment record belongs to the selected gifting workflow. A customer entering an audience is therefore a candidate observation; it is not a purchasing instruction or evidence that a gift was delivered.
Write the commercial rule in a form an operator can dispute. For example, “one anniversary invitation per verified customer per anniversary year, within the approved region and program budget” is testable. “Send a gift when engagement increases” is not. Specify the moment, eligible relationship, excluded recipients, allowed invitation channel, expiry, approval threshold and exception owner. Finance should approve the budget definition before engineering turns it into a condition.
The adapter should expose a durable decision ledger. Every candidate receives a recorded disposition: eligible, suppressed, awaiting approval, expired, duplicate, or unresolved. Keep the reason and the evidence version alongside that disposition. This lets a program owner explain why someone received nothing without searching raw profile exports or guessing from the provider’s status. Avoid saving unnecessary personal details merely to make troubleshooting convenient.
Use a controlled pilot to establish these boundaries. Restrict the first program to one event family and a small approved recipient list. Set an explicit spending ceiling and a pause switch that stops new execution while allowing status reconciliation. A paused sender must still receive and record valid lifecycle updates; otherwise operations lose visibility exactly when an incident occurs. The owner of the pause switch should be able to activate it without editing an audience definition.
Choose an activation route that your license and payload support
Verify the route before designing the receiving service. Adobe’s HTTP API destination documentation limits this destination to Real-Time CDP Ultimate and requires a receiver that accepts the Experience Platform profile schema and responds within two seconds. It does not transform that export into a third-party request schema. Consult Adobe’s current Experience Platform API reference and API fundamentals for the operations and authentication your tenant actually supports. Consequently, point this route at your adapter, rather than assuming it can call a gifting operation directly.
The recommended receiving path is short: validate the transport and schema, durably accept an observation, then acknowledge it. A background decision process performs identity resolution, current consent checks, policy evaluation and budgeting. Put costly lookups outside the inbound response path. Measure acceptance time separately from the time to make a gifting decision, so a fast acknowledgment cannot hide a stuck decision queue.
If the required destination is unavailable under your agreement, assess an approved scheduled export or a supported custom integration route against your installed capabilities. Batch activation can be a good fit when an anniversary program runs daily and immediate processing adds little value. Its tradeoff is delay and a larger reconciliation window. Do not replace a licensing gap with an undocumented polling method or an assumption about a feature you have not purchased.
Audience evaluation also has its own semantics. Review the relevant streaming segmentation guide for your tenant’s eligibility rules. Agree on an observation freshness limit for the business case instead of promising that every definition becomes immediately actionable. If a delayed candidate arrives after its invitation window, expire it or send it for review; do not move the deadline simply to clear the queue.
Design a minimum field contract and identity map
Use the Experience Data Model documentation to choose the appropriate profile and event structures. Keep your internal execution envelope separate from those structures and from any provider request. A schema mapping should name the source field, meaning, transformation, permission basis and owner. A field with the correct data type can still carry the wrong identity or purpose.
Recommended adapter field contract; these are internal concepts, not provider API parameters.
| Concept | Meaning and handling | Owner |
|---|---|---|
| Observation identity | Stable source reference plus source time; detects repeat transport observations | Data engineering |
| Recipient reference | Verified internal person reference; resolve ambiguous identity before sending | Customer data owner |
| Business opportunity | Stable program, verified person and occasion year; one entitlement across policy versions. Store the evaluated policy version separately | Program operations |
| Consent evidence | Purpose, channel, decision version and checked time; recheck before execution | Privacy owner |
| Budget authorization | Currency, cap, reservation and approving policy; never infer from audience membership | Finance |
| Provider resource reference | Returned identifier linked to the opportunity; preserved for reconciliation | Integration engineering |
Separate person identity from delivery destination. A customer may have several email addresses, and a shared mailbox may represent several people. Do not use an address change as a reason to create another anniversary opportunity. Define which verified identity is authoritative, how merges are reviewed, and when an unresolved match is suppressed. A deterministic merge policy should not be treated as proof that two real people are the same.
Send only fields required by the selected workflow. If the recipient experience can collect a shipping address later, assess whether transferring it at audience activation is necessary. Keep sensitive risk scores and detailed purchase histories out of gifting messages and ordinary support logs. Record a category of eligibility evidence where sufficient, rather than copying the full reasoning data into every downstream system.
Version the mapping contract. Test a missing optional field, an unknown enum, a malformed timestamp and an additional unexpected field. Required identity or authorization failures should quarantine the observation; unknown optional fields should not silently change the business decision. Keep a small set of synthetic fixtures so a mapping release can be compared against the prior behavior before activation resumes.
Make consent and suppression a current decision
Data-use permission, invitation permission and gift eligibility answer different questions. A person may be present in a marketing audience but excluded from gifts by an employer policy, contractual restriction or program cap. Similarly, permission for one communication purpose does not automatically establish permission for another. Have the privacy and program owners define the required evidence and its freshness for this particular workflow.
Adobe’s automatic policy enforcement guide distinguishes data-use controls from consent-policy features that require specified Shield products. More specifically, Adobe states that consent policy evaluation is not supported for exports to the HTTP API destination. Confirm the tenant’s licensed features and data-use policy configuration, then make the adapter’s current consent check an explicit release condition for this route. It also needs a rule for candidates already accepted into its queue when permission changes. Do not assume a withdrawal can reverse a gift already fulfilled.
At execution, read the current authoritative suppression and permission decision. Store its version and checked time with the opportunity. When the lookup is unavailable, hold the action rather than interpreting absence as approval. Define a maximum waiting window and a clear expired disposition. This makes a dependency outage visible without converting it into unauthorized sending or an endless backlog.
Once a withdrawal is observed, do not initiate another create request. Reconcile any request sent before that observation against its original fingerprint and resource reference; an in-flight request may finish afterward. Classify what can still be prevented: an unsent invitation, a pending provider operation, or a shipment already underway. The supported cancellation operation and its actual result determine what happens next. Record “cancellation requested” separately from “cancellation confirmed,” and have an operator communicate the limitation when physical fulfillment can no longer be changed.
Use two identities to prevent duplicate gifts
One deduplication key is rarely enough. Use an observation identity to recognize repeated transport and a business opportunity identity to recognize repeated eligibility for the same occasion. These keys serve different purposes. A corrected audience export can contain a new observation while still describing the same anniversary gift; processing it should update evidence without issuing another gift.
For a yearly anniversary, make the entitlement key from a stable program identifier, verified person and anniversary year, excluding the policy or campaign version. Choose the occasion window with the program owner, including the applicable timezone and boundary rule. Store the policy version used for each evaluation in a separate decision field. Persist a cross-version uniqueness constraint on the entitlement key before reserving funds or making a provider call. A queue lease alone is insufficient if two workers can independently decide that a candidate is new.
Model execution as explicit transitions: candidate, awaiting authorization, authorized, submission in progress, accepted with resource reference, or submission outcome unknown. Keep suppression and expiry as recorded terminal decisions for the opportunity. An unknown submission outcome requires reconciliation; it must not be converted to “failed” solely because the client did not receive a response. Store the intended request fingerprint before submission.
Separate automatic reprocessing from a deliberate replacement gift. A replacement needs a new authorized opportunity linked to the original, its reason and approver. It must not be created by deleting the old deduplication record. Retain a minimal decision reference for the approved retention period so a support correction does not erase the evidence that prevents another accidental send.
Map authorized opportunities to the right Giftpack workflow
Choose the recipient experience before implementing requests. The current Giftpack API guide separates campaign recipients from marketplace order receivers. Preserve returned resource identifiers and subscribe to the matching lifecycle event family. Confirm the required fields, account permissions and operation-specific behavior in the current reference. This design does not assume an interchangeable recipient model or a universal idempotency header.
Create a narrow provider adapter with explicit supported operations. It translates an authorized internal opportunity into the chosen provider contract and stores the result against that opportunity. Keep credentials in server-side secret storage, restrict access by environment and workspace, and prohibit credentials in browser code or exported profile data. The program owner should see business status; only authorized integration staff should access sensitive technical diagnostics.
Treat request timeouts as uncertain until reconciled. When a read operation is safe to repeat, retry it with a bounded delay and record the outcome. For a state-changing operation, first determine whether an accepted resource already exists using supported identifiers and documented lookup methods. If the available contract cannot establish that, hold the opportunity for review. Do not manufacture a lookup field or send a second request to discover whether the first one worked.
Test permission errors without broadening credentials automatically. A missing entitlement, revoked key or forbidden operation needs the authorized account owner to resolve the specific capability. Pause the affected operation and preserve its evidence. Before deployment, compare the implementation with Giftpack’s security information and your organization’s vendor review. A public security page is a review input, not a substitute for your required contractual and access decisions.
Receive lifecycle updates without confusing them with outcomes
Build a separate inbound path for provider lifecycle events. Verify authenticity using the current provider contract, durably record the event and deduplicate its identity before applying business effects. Keep raw-body handling compatible with the documented signature verification. Avoid storing raw sensitive payloads indefinitely; diagnostics and retention rules should be designed together.
Your event processor should tolerate repeated and out-of-order updates. A late preparation event must not overwrite a confirmed delivery merely because it arrived last. Preserve event time, received time and processing result, then apply allowed state transitions or request a current resource read when the sequence is ambiguous. Unknown event types should be stored safely and reviewed without triggering an unplanned gifting action.
Feed back a minimal operational result to your analytics model. Record the opportunity reference, selected workflow, relevant milestone and observation time. Do not send shipping addresses or unnecessary support conversation data back into customer profiles. Define whether a status is a provider fact, a derived operational interpretation or a manually resolved exception. Reports should retain that distinction when comparing programs.
The acceptance test is more demanding than observing one successful delivery. Replay the same event, invert two event arrivals, interrupt the processor after durable storage and restart it. Business effects should occur once, and recovery should consume the saved event rather than depend on another delivery. Independently reconcile a small sample of provider resources with the adapter ledger to detect missing events before increasing volume.
Worked case one: a customer anniversary program
This is a hypothetical design exercise, not Giftpack customer evidence. A business wants one optional anniversary gift invitation per customer year. The customer-data team supplies a daily eligible audience; the program owner defines the anniversary window and finance approves a fixed per-recipient cap. The first decision is whether daily batch processing meets the experience promise. If it does, avoid adding a streaming dependency simply for its label.
Suppose the same person appears in three accepted observations after profile corrections. All three observations are preserved, but the program-person-year opportunity is created once. The first qualified observation reserves the allowance; later observations update eligible evidence without a second reservation. If identity resolution changes the person reference, hold the merge for review rather than assuming both opportunities are independently valid.
Before sending, the adapter checks current invitation permission, supported region, remaining program allocation and exclusion rules. An unavailable consent lookup produces a waiting record, not a gift. A budget shortfall produces an approval request or an expired decision under the documented program rule. The record should say which condition stopped the invitation and who can resolve it.
Acceptance requires a synthetic recipient to receive only one authorized invitation through the approved workflow, two duplicate candidates to consume no additional allowance, and an expired candidate to remain unsent. Evidence includes the source observation references, decision version, budget ledger entry and returned provider resource. Test a year boundary, the recipient’s applicable timezone and a policy-version change for the same program/person/year key. The changed version must update decision evidence without reserving funds or creating a second invitation before expanding beyond the pilot cohort.
Worked case two: churn recovery after consent withdrawal
This second hypothetical case examines an uncomfortable race. A customer enters a recovery audience at 10:00, a candidate is accepted at 10:02, and invitation permission is withdrawn at 10:03 before execution. These times are illustrative. The adapter’s final consent check should detect the newer decision and suppress the pending action, even though the original audience observation passed its upstream checks.
Now consider a timeout during submission just before withdrawal. The adapter cannot safely conclude that nothing was created. It marks the submission outcome unknown, prevents another create operation, and reconciles using the identifiers and lookup methods the provider actually supports. If a resource exists, the operator evaluates the supported next action under the updated permission and program policy. A cancellation attempt requires a recorded response; silence is not confirmation.
The alternative is to recheck only during audience activation. That is operationally simpler but leaves a queue-time permission gap. For a discretionary recovery gift, the recommended design pays the extra lookup cost to close that gap before sending. Define a consistency target and escalation path for updates that reach the suppression service late; no architecture should imply it can eliminate every distributed-system race by naming a consent field.
The test passes when no new create request begins after withdrawal is observed, duplicate replays remain suppressed, and an uncertain pre-withdrawal submission is reconciled to the original request without an unauthorized replacement. If a resource exists, attempt cancellation only where the provider supports it and record the actual response; a previously submitted invitation may still complete. Review the event timeline, permission versions, submission fingerprint and reconciliation evidence together. Measure avoided unauthorized actions and unresolved outcomes rather than judging the recovery program only by gift volume.
Launch with an executable recovery and acceptance plan
Assign four named operating owners: the customer-data owner for identity and audience defects, the privacy owner for permission semantics, the program and finance owners for eligibility and spending, and the integration owner for transport and reconciliation. Establish an escalation window for each held disposition. A queue with no accountable owner is an accumulation mechanism, not a recovery process.
Use these release checks as evidence requests rather than ceremonial checkboxes:
-
Licensed activation route and installed features verified against the actual tenant.
-
Mapping fixtures cover malformed identity, missing authorization and schema changes.
-
Duplicate observations and concurrent submissions create one business opportunity.
-
Current consent withdrawal suppresses an already queued candidate.
-
State-changing timeout enters reconciliation instead of blind resubmission.
-
Repeated and reordered lifecycle events do not repeat business effects.
-
Pause stops execution while reconciliation and valid status ingestion continue.
-
Access and deletion procedures produce evidence across every retained system.
When a submission is stuck or its outcome is unknown
Preserve the original opportunity, request fingerprint, returned identifiers and diagnostic reference. Stop concurrent writes. Check the current documented resource state; distinguish permission failure, temporary dependency wait and an unresolved business outcome. Record the evidence and the next permitted action. Revalidate current consent and authorization before any later execution. Never replay a whole audience to repair one uncertain opportunity.
For privacy requests, Adobe Privacy Service manages jobs within its supported product scope. Your runbook must separately address the adapter, gifting provider and any authorized operational stores. Record what was requested, what was completed and what remains under an approved retention obligation. An upstream job does not itself prove deletion everywhere.
Build a controlled execution layer that operations can explain
The integration is ready to expand when every candidate has an explainable decision, each authorized opportunity has one durable identity, and uncertain outcomes have a safe reconciliation path. Review a pilot’s held cases before increasing volume. A lower sending count can be a correct result when permissions, identity or budget evidence is incomplete. Never turn a delivery metric into pressure to bypass those controls.
Documentation verified October 9, 2026 informs the platform constraints above. Tenant licensing, required request fields, cancellation behavior and operational service targets still need implementation-specific confirmation. For broader reliability decisions, see the Gift API implementation guide. Use it alongside this Experience Platform-specific field and authorization design, rather than treating either article as an executable vendor contract.
When those responsibilities are defined, Giftpack can serve as the gifting execution layer for the selected recipient experience. Your organization retains decisions about consent, eligibility, spending, privacy and legal obligations; a gifting integration should make those decisions traceable before it turns an audience signal into a real-world action.