openapi: 3.0.0
info:
version: 2.0.0
title: Opal API
license:
name: Opal API License
url: https://www.workwithopal.com/api-license
description: "The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD\
\ NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted\
\ as described in [BCP 14](https://tools.ietf.org/html/bcp14) [[RFC2119](https://tools.ietf.org/html/rfc2119)]\
\ [[RFC8174](https://tools.ietf.org/html/rfc8174)] when, and only when, they appear in all capitals,\
\ as shown here.\n\n# Other API Versions\n\nThe [v3 API](/api/documentation/v3) is less complete than\
\ the v2 API, and is still a work in progress. Currently, if a resource has endpoints in both the\
\ v2 API and the v3 API you **SHOULD** use the v2 API endpoints. At some point in the future we will\
\ recommend the v3 API instead.\n\n# Documentation Organization\n\nv2 API endpoints are categorized\
\ by stability:\n\n1. JSON:API\n2. Other\n3. Unstable\n4. Proposed\n\nv2 API endpoints in the “JSON:API”,\
\ “Unstable”, and “Proposed” categories are [JSON:API](https://jsonapi.org)-compliant ([specification](https://jsonapi.org/format/))\
\ and can be used with any [JSON:API-compliant client](https://jsonapi.org/implementations/).\n\n\
<aside>\n\nTo strictly comply with the JSON:API specification your requests for endpoints in the “JSON:API”,\
\ “Unstable”, and “Proposed” categories **MUST** set the `Accept` HTTP header to `application/vnd.api+json`.\
\ The server response’s `Content-Type` HTTP header will also be `application/vnd.api+json`.\n\nYou\
\ **SHOULD** use `application/vnd.api+json` for maximum stability, but v2 API endpoints **MAY** allow\
\ the `Accept` HTTP header to be `application/json`; if so, the response’s `Content-Type` HTTP header\
\ will be `application/json`. This support for `application/json` **MAY** disappear from a given endpoint\
\ at any time, and is not available on all endpoints.\n</aside>\n\n“Other” endpoints are stable, but\
\ do not follow the JSON:API specification. (Some “Other” endpoints have data that resembles the JSON:API\
\ structure, but **MUST** be parsed as generic JSON.) Your requests **MUST** set the `Accept` HTTP\
\ header to `application/json`, and the response’s `Content-Type` HTTP header will be `application/json`.\n\
\n## Unstable Endpoints\n\n*Note:* This generally refers resources in the “Unstable” category, but\
\ includes endpoints with a summary that’s prefixed by `[UNSTABLE]`. These `[UNSTABLE]` endpoints\
\ may be part of a “Stable” resource.\n\nThe data structure and behavior of “Unstable” endpoints are\
\ not guaranteed, and we **MAY** change them at any time. You **MUST NOT** use these endpoints for\
\ production features, but **MAY** use them as a preview of upcoming features, and we welcome feedback.\n\
\n## Proposed Endpoints\n\n“Proposed” endpoints **MUST NOT** be used (they’re not yet implemented),\
\ and we **MAY** change or remove them at any time. We publish them at our discretion to share our\
\ plans and encourage internal feedback. We also welcome your feedback.\n\n# Design Principles\n\n\
## Breaking Changes\n\nWe **MAY** expand the data for “JSON:API” and “Other” resources, but will not\
\ change or remove existing attributes or relationships for these resources. These expansions should\
\ not require any changes to your code.\n\nWe provide no guarantees for “Unstable” and “Proposed”\
\ endpoints.\n\n## Firehose Rule\n\nBy default endpoints include all the relevant data that’s accessible\
\ to the authenticated user. Clients **MAY** specify filters, ordering, pagination, sparse fields,\
\ and other limiting mechanisms to pare down the desired data.\n\n*Note:* Existing endpoints **MAY\
\ NOT** follow this maximalist approach, but new endpoints will, and we **MAY** enhance existing endpoints.\n\
\n## Obscurity\n\nIn order to provide customers with as much privacy as possible, many API calls that\
\ fail authorization will return `404 Not Found` rather than `403 Forbidden`. Do not design frontends\
\ around the expectation that a `404 Not Found` status code means a resource would not be returned\
\ given different authentication credentials.\n\n# Authentication Strategies\n## OAuth 2.0\nOpal uses\
\ OAuth 2.0 (https://oauth.net/2) to authenticate users and grant access to protected resources. After\
\ registering your application as an OAuth client, you must get permission from each user before accessing\
\ their account.\n\nThe main steps are:\n\n1. Register your application\n2. Direct the user to Opal,\
\ to authorize your application\n3. Opal confirm's user identity, and asks the user to grant your\
\ application permissions\n4. Opal issues tokens your application can use to access the user's Opal\
\ resources\n5. Your application can begin making requests to the Opal API on behalf of the user\n\
\n### Roles\n#### Client\nThe 3rd-party application accessing the API on behalf of the User.\n\n####\
\ API\nAPI endpoints used to interact with a User's resources in Opal.\n\n#### User\nThe person authorizing\
\ the Client to access to their Opal account.\n\n### Registering your application\nApplication registration\
\ is currently a manual process.\n\nTo begin, you will need to provide the following information to\
\ the Opal integrations team:\n\n- Application name\n- Logo URI\n- Redirect URI\n\nIn return, expect\
\ to receive:\n\n- Client ID\n - public\n- Application secret\n - keep this private\n - keep this\
\ written down someplace safe. Opal cannot retrieve this for you if it is lost.\n\n### Authorization\n\
For a Client to make API requests on behalf of Users, the User must first give consent.\nHere is an\
\ overview of the consent flow:\n\n1. Direct the User to grant access in Opal\n\n```\nhttps://login.ouropal.com/oauth2/auth?grant_type=authorization_code&scope=offline_access&response_type=code&client_id={client_id}&state={state}&redirect_uri={url_encoded_redirect}\n\
```\n\nParameters:\n- `client_id`: Provided by Opal.\n- `grant_type`: Set the value to authorization_code\
\ to receive a code string that can be exchanged for an access token.\n- `redirect_uri`: Defined by\
\ Client. After authentication, the user will be directed to this location.\n- `response_type`: The\
\ value code should be set for refresh tokens to be issued.\n- `scope`: The value offline_access must\
\ be present if you wish to use refresh tokens.\n- `state`: Defined by the Client. A unique value\
\ used to validate the response.\n\n\n2. If logged out, User is directed to log in to Opal\n\n3. User\
\ is redirected to consent page (if the User has not already given consent)\n\n```\nhttps://login.ouropal.com/oauth2/consent?consent_challenge=abc123\n\
```\n\n4. If the User grants permission, User is sent to the specified `redirect_uri`\n\n```\nhttps://example.com/defined-by-client?code=Mu9z2DndN7TfXSLaf99O8ReqqXqMabXhSqP5e0jlx_Q.naLKbko-GyfPJRGYcWyclxU0sBGwygPy05OSFww0XZ8&scope=offline_access&state={state}\n\
```\n\nParameters:\n- `code`: The Client may use this to get an access token.\n- `scope`: API permissions\
\ granted to the Client by the User.\n- `state`: The validation string provided by the Client in step\
\ 1.\n\nIf the User declines the consent prompt, User will be sent to the same `redirect_uri`, but\
\ with an error parameter :\n\n```\nhttps://example.com/defined-by-client?error=consent+request+denied&state={state}\n\
```\n\nParameters:\n- `error`: A brief description of the issue.\n- `state`: The validation string\
\ provided by the Client in step 1.\n\n### Retrieving Access Token\nYou must make a POST request to\
\ the token endpoint to get an access token, before the code expires:\n\n```\ncurl -X POST \\\n https://login.ouropal.com/oauth2/token\
\ \\\n -H 'Content-Type: application/x-www-form-urlencoded' \\\n -d 'code={code}&client_id={client_id}&redirect_uri={url_encoded_redirect}&client_secret={client_secret}&grant_type=authorization_code'\n\
```\n\nParameters:\n- `code`\n- `client_id`: Client ID provided by Opal.\n- `client_secret`: Client\
\ secret provided by Opal.\n- `grant_type`: Set value to authorization_code .\n- `redirect_uri`: Optional.\n\
\nIf successful, a JSON-formatted response body will contain the access_token and refresh_token:\n\
\n```json\n{\n \"access_token\":\"ABC123\",\n \"token_type\":\"bearer\",\n \"expires_in\":3600,\n\
\ \"refresh_token\":\"DEF456\",\n \"scope\":\"offline_access\"\n}\n```\n\n### Refreshing an Access\
\ Token\nOnce the access_token expires, you may generate a new one at the same token endpoint, but\
\ with different parameters.\nNote that in this request, a \"refresh_token\" parameter is used instead\
\ of \"code\", and the \"grant_type\" value is now \"refresh_token\" instead of \"authorization_code\"\
.\n\n```\ncurl -X POST \\\n https://login.ouropal.com/oauth2/token \\\n -H 'Content-Type: application/x-www-form-urlencoded'\
\ \\\n -d 'refresh_token={refresh_token}&client_id={client_id}&redirect_uri={url_encoded_redirect}&client_secret={secret}&grant_type=refresh_token'\n\
```\n\nParameters:\n- `client_id`: Client ID provided by Opal.\n- `client_secret`: Client secret provided\
\ by Opal.\n- `grant_type`: Set value to refresh_token .\n- `redirect_uri`: Optional.\n- `refresh_token`:\
\ Refresh token value\n\n### Making Authenticated Requests\n\nSet an authorization header in your\
\ requests, specifying your access token as documented here: https://tools.ietf.org/html/rfc6750#section-2.1.\n\
\n**NOTE** that the `Authorization` header supercedes the `Session-Token` header described in the\
\ documentation for many endpoints. Specifying an `Authorization` header means you do not need to\
\ specify a `Session-Token` header.\n\n```\nAuthorization: Bearer ACCESS_TOKEN\n```\n\nFor example:\n\
```\n GET /resource HTTP/1.1\n Host: server.example.com\n Authorization: Bearer mF_9.B5f-4.1JqM\n\
```\n\n### Client Revoke/Rolling OAuth secrets\nClient secrets must be kept secret and not exposed\
\ outside of the token retrieval requests. If a secret has been potentially compromised, please notify\
\ Opal as soon as possible and let us know the OAuth client id associated with the secret. We will\
\ roll/update the secret, which will invalidate all existing access and refresh tokens. Invalidating\
\ tokens will cause users to need to reauthenticate, but consent should be remembered.\n"
servers:
- url: https://login.ouropal.com
tags:
- name: Assets
description: '## Assets Overview
Assets represent images, videos, PDFs, and any other file uploads. Any upload to
the Opal platform must start with an `asset`. Some resources like `boards` can be
directly related to an `asset` while other resources like `moments` require that
you also create an `asset_reference` that further describes your `asset`.
Assets can either be created by uploading data directly or by creating a Url
Upload that requests an asset from some other publicly available web address and
streams it to Opal. The former endpoint is described immediately below and the
latter option can be found under the [Url Uploads](#tag/Url-Uploads) tag.
Once you''ve created an Asset and you have its `id`, you''ll likely want to create
an [Asset Reference](#tag/Asset-References) as well, unless you don''t want your asset exposed in
the
Asset Library or used with other resources you''ll find to have asset reference
relationships.
'
- name: Asset References
description: '## Asset References Overview
In Opal, you create `assets` to represent files uploaded to the platform and
`asset_references` to surface those assets for use in the Asset Library,
Moments, Content, and more.
Before reading into the Asset Reference endpoints, look over the [Assets
documentation](#tag/Assets).
Once you''ve created an Asset, use its `id` as the `asset_uuid` for a new Asset
Reference. You''ll also likely also want to at least copy the Asset''s `file_name`,
`bytes`, and `url` over to the new Asset Reference (into the `filename`,
`filesize`, and `full_url` fields, respectively).
The one relationship that you probably want to make sure all of your new Asset
References have is `brand`. The Brand (also known as the Workspace) must be
specified for an Asset Reference to be available for use within the workspace
you choose; it won''t even show up in the Asset Library without a Workspace
association.
'
- name: Activities
description: '## Activities Overview
In Opal, "activities" encompass both things like someone adding an asset to content and also someone
sending a chat message. In the user interface, these are called "Chat & Activity" but the underlying
resource is always an `activity` record.
This API currently supports _retrieving_ all types of activity (see the `activity_types` endpoint
to retrieve a list of supported types). It only supports _creating_ chat activity.
## Checkpoints
The `checkpoints` endpoints are how activities get marked as read for users. The idea is that any
activity older than the most recent checkpoint has been seen by the user.
## User @mentions
User mentions are represented in the plaintext body of activity messages. You can create them (or
interpret them) using the following syntax:
```
@[{{user name}}](user:{{user_id}})
```
The double-bracketed `{{user name}}` should be replaced with the user''s full name (not their "username"
or email) and `{{user_id}}` should be replaced with the user''s _integer_ id value (not a UUID). Do
not use quotation marks or spaces (except between the parts of a user''s name). For example, `[John
Doe](user:1234)`.
'
- name: Labels
description: '## Labels Overview
In Opal, Labels are a useful way of categorizing resources to be filtered or grouped.
### Label Inheritance
Labels follow StoryFirst inheritance rules. This means that **Content** inherits labels from **Moment**
which inherits labels from **Story**. **Content** also inherits labels from the selected **Account**.
If a **Moment** belongs to more than one **Story**, labels are inherited from all related stories
(i.e. the labels inherited comprise the union of the labels for each story).
For example:
Inheritance is "broken" when one or more labels is explicitly set directly on a resource. For example,
if you set the labels _x_ and _y_ for a piece of **Content**, that content will then only be considered
to have exactly the labels _x_ and _y_ and no longer the labels of its parent **Moment** or **Story**
(or associated **Account**). The default behavior of the Opal Web frontend is actually such that when
**Content** gets explicit direct labels, it takes on all existing inherited labels _and_ the new direct
labels, but it does not gain new inherited labels going forward. This behavior is achieved by requesting
all of the current labels for that **Content** and then explicitly setting the new labels to all existing
inherited labels plus the new labels.
Inheritance can also be broken by explicitly setting labels on a **Moment**. Using our _x_ and _y_
labels again:
Notice that **Content** still inherits from **Moment** and **Account** even when **Moment** stops
inheriting from **Story**.
'
- name: Stamps
description: '## Stamps Overview
In Opal, a Stamp acts as a pre-configured template for creating `moment`s or `content`. The `stamp_type`
attribute specifies if the stamp is intended for moments or content.
### Types of Stamps
- Moment Stamp: Incorporates all content, notes, and labels from a moment.
- Content Stamp: Consists of copy, assets, workflow, notes, and labels. (Note: "Content" and "Post"
are interchangeable terms.)
### Stamp Operations
- Creating a Stamp: Use the Moment Shroud feature in the Opal application to establish a moment or
content as a templated stamp. Creating a stamp via the REST API is not currently supported.
- Managing Stamps: Opal admins can manage stamps via the Configure Workspace panel.
- Retrieving Stamps: Fetch a list of stamps with the GET request /stamps/v2?brand_id={{brand_id}}.
### Using Stamps
- In the REST API: Specify the `stamp_id` attribute when creating a `moment` to apply a chosen stamp.
Note that applying a stamp via the REST API for `content` is not currently supported.
- In the Opal Application: Use the "Apply Stamp" option in the moment shroud to apply a stamp to a
newly-created moment or piece of content.'
- name: Workflows
description: "## Workflows Overview\nIn Opal, a workflow is an arrangement of tasks and approvals required\
\ to progress through the lifecycle of a \nStoryFirst resource. \n\n**Historical Note:**\n*The v2\
\ Workflows API will supersede the v2 [Phase Items](#tag/Phase-Items) API, although initial rollout\
\ will only include support for\nWorkflow on Moments which means there will be a period of time during\
\ which the Phase Items API remains the API\nfor Content Workflows.*\n\n### Workflow / Phase Items\
\ Translations\nThe following resources described below for the v2 Workflows API have fairly direct\
\ translations to the older Phase Items API.\n\n- A _workflow_ was known as a _phase group_.\n- A\
\ _stage_ was known as a _phase_.\n- An _assignment_ was known as a _phase item_.\n\n### Context\n\
Workflows from the v2 Workflow API have an optional `context` relationship. These contexts tie workflows\
\ to the resources against\nwhich the workflow is being performed. Currently only the **Moment** context\
\ is supported.\n\nA workflow without a `context` is a reasonable thing to think about: Such a workflow\
\ might have common stages that apply broadly\nin more than one context. Although a workflow can conceptually\
\ be created without a context, it must be given a context before it can\nbe started.\n\nCurrently,\
\ the capabilities supported by contextless workflows are not built out in the Opal Platform. API\
\ requests should be made to\ncreate contexts for all workflows before building them out or starting\
\ them.\n\n**Important:** Contexts tie workflows to resources from neighboring services; although\
\ Opal has one coherent v2 API, a client must\nrequest StoryFirst resources (like `moment`s) from\
\ other services rather than `including` them on Workflow requests. For example,\na Workflow might\
\ have a `context` with a `moment_id` of `'3432'`; the client would make a request to `moments/v2/3432`\
\ to retrieve\ndetails for that Moment.\n\nSee the documentation on [`POST` **Create a Context**](#tag/Workflows/operation/CreateContextV2)\
\ for more information.\n\n### Resources\nA `workflow` is arranged into `stage`s, each of which is\
\ a `circuit_breaker`, an `approval` stage, or a `task` stage.\nAll stages can optionally specify\
\ a `due_date`, but if `null` then the due date is left up to interpretation of the user\nof the workflow\
\ -- For a Moment Workflow, perhaps the due date is the `scheduled_date` of the Moment, or perhaps\n\
the exact date is not important.\n\nAssignments are completed by `POST`ing `response`s. Circuit breakers\
\ and tasks can be completed and approvals can be\napproved or declined. An approved response can\
\ be superseded by a following declined response on the same assignment.\nSimilarly, tasks can be\
\ \"undone\" after being marked complete by sending a follow-up response. Responses are a ledger with\n\
the most recent response representing the current state of the assignment.\n\n#### Circuit Breaker\n\
Circuit breakers generally just contain one assignment. When the assignment is completed, the circuit\
\ breaker is completed\nand the following stage becomes active. Circuit breakers allow workflows to\
\ pause between any two stages and they are used\nto create the initial pause before a workflow is\
\ started (giving users time to build a workflow out before beginning work\nagainst it).\n\n#### Approval\n\
Approval stages can contain any number of approval `assignment`s. They can be configured such that\
\ all of those approvals\nmust be given for the workflow to progress (`metadata.completion_rules.all`)\
\ or they can be configured such that the workflow\nprogresses after any one of the approvals is given\
\ (`metadata.completion_rules.one`).\n\n##### Approval Response\nEach approval `response` can be either\
\ `approved` or `declined` and it can optionally contain a message from the approver.\n\nAs noted\
\ above, any number of responses can be given on a single assignment; the most recent response represents\
\ the state\nof the approval: approved, declined, or in the absence of a response, simply incomplete.\n\
\n#### Task\nTask stages can contain any number of task `assignment`s. A task stage is complete after\
\ all assignments within it have been\ncompleted.\n\n##### Task Response\nEach task `response` can\
\ be either _complete_ (`complete: true`) or _incomplete_ (`complete: false`).\n\nAs noted above,\
\ any number of responses can be given on a single task; the most recent response represents the state\
\ of the\ntask: complete or incomplete.\n\n### Templates\nCreation of a new workflow often involves\
\ creating a handful of the same resources every time. For this reason, there are templates\nthe allow\
\ you to create one of two types of workflows more easily. You always get a `circuit_breaker` with\
\ one assignment at the start\nand then you get either an `approval` or a `task` `stage` next, again\
\ with one assignment. All assignments start out unassigned.\n\nSee the documentation on [`POST` **Create\
\ a Workflow**](#tag/Workflows/operation/CreateWorkflowsV2) for more information.\n\n### Rewinding\n\
Workflows can be \"rewound\" to undo some portion of them. \n\n**The big caveat being:** You are not\
\ allowed to rewind back to the start of (or before) a completed final approvel stage. Final approval\n\
stages (i.e. the last approval stage in a workflow) are special because they can have side effects\
\ that cannot be taken back --\nif workflow completion resulted in publishing to a third party platform,\
\ for example, then rewinding back to an unapproved state for the\nworkflow would leave the workflow\
\ unrepresentative of the fact that something had already been published.\n\nSee the documentation\
\ on [`PATCH` **Rewind a Workflow**](#tag/Workflows/operation/RewindWorkflowV2) for more information.\n"
- name: secondary_resources
x-displayName: Secondary Resources
description: "<!-- \n References to #/components below can be found in the opal.yml document that\n\
\ includes this markdown file.\n-->\n\n## Link\nA Link resource.\n\nFor Content composed of compound\
\ data types, a Link is sometimes used to\nconnect a given schema (called a `linkable`) to a `link_data`\
\ resource.\n<SchemaDefinition schemaRef=\"#/components/schemas/link\" />\n\n## Link Data\nA Link\
\ Data resource.\n\nFor some content composed of compound data types, a link data resource\ncontains\
\ information on link sections within a body of content, such as\nthe link destination url, visible\
\ domain, and title text. Link Data\nresources are attached to content through a `Link` resource.\n\
<SchemaDefinition schemaRef=\"#/components/schemas/link_data\" />\n\n## Option\nAn Option resource.\n\
\nFor Content composed of compound data types, an Option acts a prototype for a modifiable section\
\ within the content. The relationship to a Post Option can be thought of as the concrete expression\
\ of an Option, where the Option's `system_name` indicates the type of Post Option.\n<SchemaDefinition\
\ schemaRef=\"#/components/schemas/option\" />\n\n## Option Value\nAn Option Value resource.\n\nWithin\
\ the content system, an Option Value is an optional relationship on\na Post Option used for defining\
\ pre-set values for a specific type of\nOption. If a Post Option has a `null` value attribute, it\
\ will instead\nhave an Option Value relationship where the `display_name` attribute of\nthe Option\
\ Value is effectively the value of the Post Option.\n<SchemaDefinition schemaRef=\"#/components/schemas/option_value\"\
\ />\n\n## Post Component\nA Post Component resource.\n\n<SchemaDefinition schemaRef=\"#/components/schemas/post_component\"\
\ />\n\n## Post Option\nA Post Option resource.\n\nFor Content composed of compound data types, a\
\ Post Option stores a value\nfor a given field on a piece of Content either directly in it's own\n\
`value` field, or through its relationship to an `option_value`.\n<SchemaDefinition schemaRef=\"#/components/schemas/post_option\"\
\ />\n"
x-tagGroups:
- name: JSON:API
tags:
- Accounts
- Activities
- Annotations
- Asset Reference Options
- Asset Reference Usage Rights Options
- Asset References
- Assets
- Brand Settings
- Brands
- Checkpoints
- Content
- Delivery Records
- Label Sets
- Labels
- Messages
- Moments
- Phase Items
- Placements
- Post Types
- Privacy
- Reactions
- Rich Texts
- Services
- Stamps
- Stories
- Url Uploads
- User Domain Views
- Users
- Workflows
- name: Other
tags:
- Budgets
- URL Previews
- Search
- Stories V1
- name: ⚠️ Unstable
tags: []
- name: Additional Resources
tags:
- secondary_resources
components:
schemas:
account:
title: account
type: object
nullable: false
required:
- id
- type
- attributes
- relationships
additionalProperties: false
properties:
id:
type: string
pattern: ^[0-9]+$
nullable: false
type:
type: string
nullable: false
enum:
- account
attributes:
type: object
nullable: false
required:
- name
- uuid
additionalProperties: false
properties:
name:
type: string
nullable: false
uuid:
type: string
format: uuid
nullable: false
relationships:
type: object
nullable: false
required:
- service
- brand
- dispatch_provider_account
- placements
additionalProperties: false
properties:
service:
type: object
nullable: false
required:
- data
additionalProperties: false
properties:
data:
type: object
nullable: false
required:
- id
- type
additionalProperties: false
properties:
id:
type: string
nullable: false
type:
type: string
nullable: false
enum:
- service
brand:
type: object
nullable: false
required:
- data
additionalProperties: false
properties:
data:
type: object
nullable: false
required:
- id
- type
additionalProperties: false
properties:
id:
type: string
nullable: false
type:
type: string
nullable: false
enum:
- brand
dispatch_provider_account:
type: object
required:
- data
additionalProperties: false
properties:
data:
type: object
nullable: true
required:
- id
- type
additionalProperties: false
properties:
id:
type: string
type:
type: string
enum:
- dispatch_provider_account
placements:
type: object
nullable: false
required:
- data
additionalProperties: false
properties:
data:
type: array
items:
type: object
nullable: false
required:
- id
- type
additionalProperties: false
properties:
id:
type: string
nullable: false
type:
type: string
nullable: false
enum:
- placement
asset:
title: asset
type: object
required:
- id
- type
- attributes
- relationships
additionalProperties: false
properties:
id:
type: string
format: uuid
type:
type: string
enum:
- asset
attributes:
type: object
required:
- bytes
- created_at
- download_url_override
- duration
- file_extension
- file_name
- height
- mime_type
- updated_at
- url
- width
additionalProperties: false
properties:
url:
type: string
nullable: false
download_url_override:
type: string
nullable: true
description: 'An alternative download URL for the file. If set, downloading the
asset will result in a redirect to the overridden location instead of
downloading the asset data directly. When not present, `url` should
be used.
'
width:
type: integer
nullable: true
description: When applicable, the width in pixels of an image or video.
height:
type: integer
nullable: true
description: When applicable, the height in pixels of an image or video.
duration:
type: integer
nullable: true
description: When applicable, the play time of a video in seconds.
pages:
type: integer
nullable: true
description: When applicable, the number of pages in a PDF document.
mime_type:
type: string
nullable: false
description: The [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types)
that corresponds to the uploaded file.
file_name:
type: string
nullable: false
file_extension:
type: string
nullable: false
bytes:
type: integer
nullable: false
description: The size of the
# --- truncated at 32 KB (2912 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/opal/refs/heads/main/openapi/opal-v2-openapi.yml