Marketing automation connects systems that often store different representations of the same person or activity. A commerce platform might record an order, an email platform might maintain subscription status, and an internal application might hold an account identifier. An integration transfers specified information between those systems; it does not automatically make their records equivalent. This reference explains requests, responses, events, credentials, and data mapping, using documented Mailchimp and Shopify behavior where useful. Platform-specific features are identified rather than treated as universal rules. The scope is the mechanics of information exchange, not recommendations about software or workflow priorities. Message stages and triggers are covered separately in Email Lifecycle Marketing.
Requests, responses, and API operations
An application programming interface defines how software interacts with another software component. For a web API, a client commonly sends an HTTP request to an endpoint and receives an HTTP response. The request includes a method, a target address, headers, and sometimes a body. The response includes a status code, headers, and potentially a representation of data. These components have distinct meanings in HTTP semantics.
GET requests retrieve a representation; POST asks the target resource to process the enclosed representation according to that resource’s rules. An endpoint’s documentation supplies the actual operation and accepted fields. A successful HTTP response is not necessarily proof that every later business action has finished. For example, the meaning of an accepted asynchronous job differs from a completed update. The endpoint contract, rather than the marketing label attached to an integration, determines that distinction.
Events and webhook delivery
An event records something that happened, such as a subscription change. A webhook is a mechanism for delivering information about selected events to a configured receiving address. In Mailchimp’s documented audience webhooks, that address accepts HTTP POST requests, and supported notifications include subscriptions, changed email addresses, and campaign sending. This is a platform-specific event catalogue, not a universal set of webhook types. Mailchimp documentation describes the available exchange.
Polling and webhook delivery differ in who initiates the check. With polling, a client repeatedly requests information. With webhooks, the event provider initiates delivery after a qualifying occurrence. A webhook is still an HTTP request in this example; it is not an alternative transport protocol to HTTP. Its response acknowledges the delivery according to the provider’s contract, rather than constituting a new marketing event.
Payloads and field meaning
A payload is the data carried by a message. JSON represents values using objects, arrays, strings, numbers, booleans, and null, as specified in RFC 8259. Using JSON does not establish a shared business vocabulary. Two systems can both exchange valid JSON while disagreeing about whether a field means account creation time, subscription time, or the most recent update.
In a hypothetical exchange, a commerce event contains an order identifier, customer identifier, currency, and total. A receiving system maps those values to its own fields. Whether the total includes shipping or tax cannot be inferred from its numeric type. Similarly, a timestamp needs an agreed interpretation and representation. Missing values and explicit null values are not interchangeable assumptions: their permitted meaning belongs to the individual schema and operation.
Authentication and delivery verification
Authentication verifies the identity or authenticity asserted by a request, commonly by validating credentials; authorization determines which operations or resources the authenticated principal may access. Mailchimp Marketing API documentation distinguishes account API keys from OAuth 2 credentials for integrations accessing another account. Credentials authenticate API calls, but do not by themselves demonstrate a contact’s permission to receive marketing. The current Mailchimp fundamentals describe version 3.0 and its authentication context.
Webhook verification is a separate interaction. Shopify’s HTTPS deliveries include an X-Shopify-Hmac-SHA256 header calculated from the raw request body using the app’s client secret. The receiver can calculate the signature and compare it with the supplied value. Parsing and reserializing the body can change the bytes used in that calculation. These details are specific to Shopify’s verification protocol, not requirements that apply identically to every provider.
Mapping identities and subscription states
Data mapping associates source fields and values with their destination equivalents. It can involve renaming fields, translating enumerated values, changing formats, or resolving identifiers. In a hypothetical integration, an internal customer number links an application record to an email-platform contact. That mapping does not mean an email address and a customer number are interchangeable identifiers, or that an address will remain unchanged indefinitely.
Subscription state illustrates the difference between record synchronization and message eligibility. A profile may exist in multiple applications while marketing permission differs by channel or audience. Mailchimp’s webhook documentation includes subscription and unsubscribe updates, enabling an external database to receive those changes. A transfer that copies a name or email field alone does not also explain how subscription changes are represented. The documented webhook example makes this state exchange explicit.
Duplicates, acknowledgements, and errors
Webhook delivery is not equivalent to exactly-once execution of a downstream task. Shopify documents X-Shopify-Webhook-Id for identifying duplicate webhook deliveries; X-Shopify-Event-Id identifies the underlying event, which can generate multiple notifications. Processing the same notification twice can otherwise create two downstream actions even though only one business event occurred. Recording an identifier and recording completion describe different pieces of processing state. Shopify’s delivery verification documentation separates signature verification from duplicate detection.
Idempotence means that multiple identical requests have the same intended server effect as one such request; it does not require identical responses. HTTP defines this property for particular methods, but arbitrary business actions do not inherit it merely because they use HTTP. Authentication failures, invalid fields, and server errors also represent different failure categories. RFC 9110 defines status-code semantics; provider documentation specifies the accompanying error details.
A documented exchange and its boundaries
Mailchimp’s audience-webhook guide describes keeping an application database synchronized when someone subscribes or unsubscribes. The platform sends a configured notification to an application callback. The application interprets the event and updates its own stored state. In the opposite direction, the Marketing API provides programmatic access to audience and campaign functionality. Together these illustrate notification delivery and requested operations without making them the same mechanism. Mailchimp fundamentals explain these complementary roles.
A hypothetical extension could use a received update to change an internal reporting record. That is an illustration, not a documented client implementation or a claim about results. The exchange description still needs the event definition, record identifier, accepted fields, credential context, and response meaning. The related automation service page describes service scope; it does not replace the technical contracts that govern individual integrations.
Frequently asked questions
Is a webhook an API?
A webhook is an event-notification mechanism that often uses HTTP endpoints. “API” is broader: it describes an interface through which software interacts. In the examples here, an API call requests an operation, whereas a webhook delivers a configured notification.
Do all webhooks use JSON?
No. The provider defines the payload encoding and schema. JSON is one representation, not part of the definition of a webhook. Receivers interpret the documented content type and fields rather than assuming that every provider sends the same structure.
Does an API key establish marketing consent?
No. An API key authenticates software access to an account. Marketing permission is a separate attribute or legal consideration concerning the contact, channel, and message. Successful authentication does not change that distinction.
Can one event produce duplicate deliveries?
Yes. Shopify explicitly documents duplicate detection using X-Shopify-Webhook-Id for webhook deliveries. A business event, a delivery attempt, and a completed downstream action are separate records of activity; their counts need not be identical.
Does a successful response prove an email was sent?
Only if the documented operation and response explicitly establish that outcome. A response may instead confirm receipt, record creation, or acceptance of asynchronous work. HTTP success and completion of a later marketing action are different facts.