Adobe I/O Events Frequently Asked Questions (FAQ)

General Questions

Which events are currently supported by Adobe I/O Events?

Adobe I/O Events regularly adds new event providers. As of now, the following Adobe solutions are supported:

• Adobe Campaign Standard
• Adobe Commerce
• Adobe Document Cloud
• Adobe Experience Manager (AEM)
• Adobe Experience Platform Notifications
• Adobe Experience Platform Privacy Service
• Adobe Experience Platform Data Hygiene
• Analytics Triggers
• Asset Compute
• Asset Events (Creative Cloud)
• Cloud Manager
• Content Log Events
• Globalization Content Service
• Imaging APIs
• InDesign APIs
• Marketo Data Streams
• You can also register your own Custom Events Provider

What is the guarantee of events delivery?

Adobe I/O Events provides durable delivery. Each event is delivered at least once for each registration. If your webhook endpoint does not acknowledge receipt of the event delivery, Adobe I/O Events retries delivery. See the Webhook FAQ for more details.

Important notes:

• Event order is not guaranteed. Events may arrive out of order (applies to Journaling API as well).
• Duplicate events may be sent.
• Each event payload includes a unique event UUID.
• The same UUID is included in the x-adobe-event-id header of the webhook request.

Do you guarantee the order of events delivery?

No. Event order is not guaranteed. See the previous answer for details.

What permissions are required to use Adobe I/O Events?

Permissions and entitlements depend on the event provider:

• Some providers are available to all Adobe customers.
• Others require enterprise developer or administrator access.
• Some providers require licensing.

For licensing questions, contact your Adobe account manager.

Which subscription types does Adobe I/O Events support?

Adobe I/O Events supports the following subscription types:

• For near-real-time notifications (push model):

  • Webhooks
  • Runtime actions as Webhooks
  • Amazon EventBridge

• For batch retrieval of events (pull model):

  • Journaling API

What should I do if I am unable to delete a project because of a conflicting provider?

If you see an error when deleting a project in the Developer Console, it may be due to an event provider associated with the same workspace. You must delete the event provider before deleting the project.

Steps to resolve:

1. In the Developer Console, select "Project overview" from the left menu.

2. Click "Download" in the top menu to download the project metadata JSON file.

3. Open the JSON file and note:

   • Consumer organization ID (project.org.id)
   • Project ID (project.id)
   • Workspace ID (project.workspace.id)

4. Use the Provider API documentation to fetch your I/O Events providers for the organization id.

5. Find the provider with the matching workspace id. Note the provider id.

6. Delete the provider using the Provider API and the ids from above.

7. Repeat for all conflicting providers, then try deleting the project again.

Why do I see duplicate fields for recipient client ID and event ID in the delivered payload?

Adobe I/O Events delivers payloads with both the new and deprecated attribute names for recipient client ID and event Id to ensure compatibility during the transition to stricter CloudEvents specification compliance.

You may see all four fields in your event payload:

• eventid (CloudEvents-compliant, new)
• recipientclientid (CloudEvents-compliant, new)
• event_id (deprecated)
• recipient_client_id (deprecated)

Why are there duplicate fields?

• The new attributes eventid and recipientclientid follow the CloudEvents attribute naming convention and are required for future compatibility.
• The old attributes event_id and recipient_client_id are included temporarily to avoid breaking existing integrations.
• Both sets of fields carry the same values in each event payload.

Action required:

• Update your integration to use the new eventid and recipientclientid fields.
• The deprecated fields (event_id, recipient_client_id) will be removed by the end of 2025.
• We recommend migrating as soon as possible to ensure continued compatibility.

Webhook FAQ

What happens if my webhook is down? Why is my event registration marked as Unstable?

If your webhook is down, Adobe I/O Events retries delivery (see details below). Your event registration may be marked as Unstable.

If Adobe I/O Events fails to receive a successful response code from your webhook within the configured timeout window, it retries the request, including a special header x-adobe-retry-count. This header indicates how many times the delivery of an event or a batch of events has been attempted.

• Default webhooks: The timeout is 10 seconds.
• Runtime Actions as webhooks: The timeout is 60 seconds.

Note: The timeout spans the entire delivery attempt, including the overhead of setting up the HTTP connection. This means that if your webhook handler responds in exactly 10 seconds (or 60 seconds for Runtime Actions), the delivery will still fail due to the additional overhead of setting up the connection.

data-variant=info

data-slots=text

Adobe I/O Events will keep on retrying delivery to your webhook for 24 hours using exponential and fixed backoff strategies. The first retry is attempted after 1 minute and the period between retries doubles after each attempt, but is at most 15 minutes (see below table outlining the retry pattern).

Please note that above retry intervals are not guaranteed and may vary in few exception scenarios.

Adobe I/O Events changes the state of an event registration based on the below criteria:

• UNSTABLE - Event registration is marked as unstable if, in the last 30 minutes, over 80% of at least 10 deliveries were unsuccessful.
• DISABLED - Event registration is marked as disabled if, in the last 24 hours, over 80% of at least 10 deliveries were unsuccessful.
• ACTIVE - Event registration is marked as active if, in the last 30 minutes, over 80% of at least 10 deliveries were successful.

For an Unstable event registration Adobe I/O Events still keeps on attempting delivery. This gives you sufficient time to restore your webhook, and avoid it from getting marked as Disabled. Once restored, it will be marked as Active on the next successful event delivery.

If all retry attempts get exhausted and the event still isn't delivered (webhook not responding or responding with a non 2XX response) or the registration is still in Unstable state, Adobe I/O Events drops the events, marks the event registration as Disabled, and stops sending any further events.

An email notification is sent to the admins of the organization when a webhook endpoint is marked as Unstable or Disabled.

Here you can see a sample email notification sent when a registration is marked as Unstable:

A similar email notification is sent when a registration is marked as Disabled.

You can use the Journaling API to retrieve events published while your webhook was down. Once your webhook is restored, you can re-enable your event registration (see next question).

How can I re-enable my event registration after downtime? How can I retrieve missed events?

1. Fix the issue preventing your webhook from responding.
2. Log in to the Adobe Developer Console.
3. Edit your event registration. This triggers a webhook challenge request and re-activates your registration.

While your registration is disabled, Adobe logs events in your Journal. You can retrieve all events for the past 7 days using the Journaling API documentation.

What happens if my webhook cannot handle a specific event but handles others?

• If delivery fails with any of the following status codes, Adobe I/O Events retries delivery.

  • 429 Too Many Requests
  • 5xx error codes (except 505 HTTP Version Not Supported)
  • 6xx error codes (Adobe I/O Events custom error codes)

• Other status codes are not retried.

• Retries continue for 24 hours. If all attempts fail, the event is dropped.

• The event registration remains Active and continues processing other events.

What are non-standard 6xx webhook status codes?

Adobe I/O Events uses custom 6xx status codes to indicate specific issues when no HTTP response is received from your webhook server. See Debug Tracing: 6xx Custom Status Codes for details.

Does every Adobe I/O Events webhook HTTP request include a signature?

Yes. Every request includes a x-adobe-signature header, including the initial challenge GET request. See Security Considerations for more information.

Do Adobe I/O Events notifications come from static IPs?

No. Adobe I/O Events notifications are sent from AWS and Azure, and their IPs change over time.

Security note:

• Each request includes a signature header (see above).
• If you require static IPs, use the pull model and the Journaling API.

What is the size of notifications in batch delivery style?

When registering a webhook, you can choose the delivery style:

• Single: One event per HTTP request.
• Batch: Multiple events per request. Batch size is up to 2MB and a maximum of 20 events. Please note that the batch size may vary depending on the incoming traffic.

How can I debug and see logs for successful invocations to my runtime action (configured as webhook)?

To debug successful invocations, relay the activation_id of your target user action as a response header (e.g., x-target-action-activation-id). This allows you to trace activations in the Developer Console without enabling the x-ow-extra-logging=on header (which also impacts Runtime performance).

Journaling FAQ

How far back are I/O Events available via the Journaling API?

Adobe I/O stores 7 days of subscribed events, retrievable via the Journaling API.

Why do I only get one event, regardless of the limit I use?

The Journaling API limit parameter sets the maximum number of events returned. You may receive fewer events than the limit, depending on the incoming traffic. This is expected. For example, you may only see a single event in a journal batch/page even when the journal holds more than 1 event. See the Journaling API documentation for details.

Can I retrieve all events in one request?

No. The Journaling API does not support retrieving all events in a single query. Use the since parameter and follow the journal's rel=next Link to fetch events incrementally.

Can I start fetching events from a specific point in time?

Yes. Use the seek parameter with the Journaling API to start from a specific point in time, using an ISO 8601 duration (e.g., -PT2H for 2 hours ago, -P1D for 1 day ago). This is especially useful for investigating events within a particular time window. See the Journaling API documentation for examples.

Custom Events FAQ

Why is my Custom Events Provider not showing up in the Adobe Developer Console?

If you create a Custom Events Provider using the Provider API, it will only appear in the Adobe Developer Console after you create at least one Event Metadata associated with it.

After associating Event Metadata:

• The provider appears in your Developer Console project.
• You can register against it.
• You can emit events using the Events Publishing API.

Does Custom Events Provider support high volume? Is there a throttling policy?

Yes, there is a throttling policy. See the Events Publishing API guide for details. For high-volume use cases, contact Adobe to discuss your needs.