Skip to content

[ZEA] SIG-4790 - [PREMIUM] Dev Documentationon is unclear, only the V1 Events API uses the contexts JSON array to make images available#137

Open
pd-rae-stg[bot] wants to merge 1 commit into
mainfrom
fix/sig-4790-clarify-images-vs-contexts-api-differences
Open

[ZEA] SIG-4790 - [PREMIUM] Dev Documentationon is unclear, only the V1 Events API uses the contexts JSON array to make images available#137
pd-rae-stg[bot] wants to merge 1 commit into
mainfrom
fix/sig-4790-clarify-images-vs-contexts-api-differences

Conversation

@pd-rae-stg
Copy link
Copy Markdown

@pd-rae-stg pd-rae-stg Bot commented May 13, 2026

Automated Customer Investigation Remediation

This PR contains an automated fix for the customer investigation described in the above Jira ticket, generated by the jira plugin's triage skill. Please
review it carefully before merging as this PR was automatically generated.

Jira Ticket: SIG-4790 - [PREMIUM] Dev Documentationon is unclear, only the V1 Events API uses the contexts JSON array to make images available

Fix Details

Perfect! The documentation has been successfully updated and pushed to GitHub. Let me provide the analysis summary:


Analysis Summary - SIG-4790

Issue Description

Customer reported that the developer documentation is unclear about the differences between Events API v1 and v2 regarding how images are attached to alerts. The confusion arises because:

  • V1 Events API uses a contexts array with typed objects (e.g., type: "image")
  • V2 Events API uses separate images and links arrays without a type field

Additionally, the documentation didn't clearly specify that image URLs must point directly to image files (not web pages) and must be publicly accessible by PagerDuty.

Root Cause

The documentation lacked clear cross-references and explicit warnings about the structural differences between API versions. Developers migrating from v1 to v2 (or vice versa) could easily miss this critical distinction, leading to failed image attachments.

Fix Applied

Updated documentation in the PagerDuty/developer-docs repository with the following changes:

  1. Added clarifying notes to Events API v2 documentation (docs/events-API-v2/02-Trigger-Events.md):

    • Added a prominent note in the "Context Properties" section explaining that v2 uses images array directly
    • Cross-referenced v1 documentation showing the different approach
    • Enhanced src field description to specify that URLs must point directly to image files and be publicly accessible
  2. Added clarifying notes to Events API v1 documentation (docs/events-API-v1/02-Trigger-Events.md):

    • Added a prominent note in the "Contexts" section explaining that v1 uses contexts array with typed objects
    • Cross-referenced v2 documentation showing the different approach
    • Enhanced src field description with the same clarity about direct image URLs

Example Clarification

The documentation now clearly shows:

V1 API Format:

"contexts": [
  {
    "type": "image",
    "src": "https://example.com/image.png"
  }
]

V2 API Format:

"images": [
  {
    "src": "https://example.com/image.png"
  }
]

Testing & Validation

  • Documentation changes follow existing markdown conventions
  • Cross-references use proper relative paths
  • Added notes are prominently placed in both API version docs
  • Changes are backward compatible (documentation only)

Impact

  • Resolves customer confusion about API version differences
  • Prevents future support tickets about failed image attachments
  • Provides clear migration guidance for developers moving between API versions
  • Documents the requirement that URLs must point directly to image files

Review Checklist

  • Verify the fix matches the customer issue described in the ticket
  • Confirm tests pass
  • Check for any unintended side effects

Addresses customer confusion (SIG-4790) about how images are attached
differently between Events API v1 and v2:

- V1 uses `contexts` array with `type: "image"` objects
- V2 uses `images` array directly without a type field

Changes:
- Added cross-reference notes to both v1 and v2 docs explaining the
  structural differences
- Clarified that image URLs must point directly to image files, not
  web pages containing images
- Specified that URLs must be publicly accessible by PagerDuty

This helps developers understand why their v1-style `contexts` payloads
don't work in v2, and vice versa.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Every `context` must have a `type`. There are a few different types of contexts supported; the fields allowed and required depend on the context type.

> **Note:** Events API v1 uses the `contexts` array with typed objects (e.g., `type: "image"` or `type: "link"`) for attaching assets to incidents. This is different from [Events API v2](../../docs/events-API-v2/02-Trigger-Events.md#context-properties), which uses separate `images` and `links` arrays without a `type` field. When migrating to v2, update your payload structure accordingly.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels strange to do this for only one of the differences between v1 and v2 -- maybe there should be something more like a migration guide?

------ | -------- | -----------
`type` | Yes | The type of context being attached to the incident. For image contexts, this must be `image`.
`src` | Yes | The source (URL) of the image being attached to the incident. This image must be served via HTTPS.
`src` | Yes | The source (URL) of the image being attached to the incident. This image must be served via HTTPS. The URL must be publicly accessible by PagerDuty and must point directly to an image file (e.g., `.png`, `.jpg`, `.gif`), not to a web page containing an image.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is only true when the type is image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants