openapi: 3.0.0
info:
version: 3.0.0
title: Opal API (⚠️ WIP)
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 [v2 API](/api/documentation/v2) is more complete than\
\ the v3 API. 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\
*Note:* Endpoints will be added to the v3 API as needed, and we will continue to support all v2 API\
\ endpoints in the “JSON:API” and “Other” categories, even if we add an equivalent v3 API endpoint.\n\
\n# Key differences between v2 and v3 APIs\n\n## Resource Identifiers\n\nThe v3 API uses a different\
\ format for primary resource identifiers than the v2 API. Responses from v3 API endpoints include\
\ the resource’s v2 API id in the `attributes.legacy_id` field, in case you need to use both API versions.\
\ (v2 API resource identifiers are generally integers, but v2 API endpoints **MAY** use a different\
\ format.)\n\n*Note:* These are opaque strings, and you **MUST NOT** rely on the structure. Currently\
\ newly-created resources have a UUIDv4 identifier, but this behavior **MAY** change at any time.\
\ Existing identifiers will not be affected.\n\n# Documentation Organization\n\nv3 API endpoints are\
\ categorized by stability:\n\n1. Stable\n2. Unstable\n3. Proposed\n4. Experimental\n\nAll v3 API\
\ endpoints 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\
Your requests **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\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 “Stable” 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,” \"Experimental,\" or “Proposed” endpoints.\n\n## Firehose Rule\n\n\
By 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\n\
3. 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\nFor 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: Custom Fields
description: "## Custom Fields Overview\n\nCustom Fields let you create custom inputs, the value of\
\ which can then be associated with a Moment, and allow your users to track dimensions based on your\
\ specific needs.\n\n- **[Custom Fields](#tag/Custom-Fields)**: An admin within a workspace can create\
\ a custom field to store new attributes on a [Moment](#tag/Moments/operation/CreateMomentV3).\n-\
\ **[Custom Field Types](#tag/Custom-Field-Types)**: The available types of custom fields which an\
\ admin can create, such as a Date input.\n- **[Moment Custom Fields](#tag/Moment-Custom-Fields)**:\
\ This resource lets one assign a ``value`` to the given Custom Field for the given Moment. Note that\
\ the expected attribute to use\non this resource is determined by the [Custom Field Type](#tag/Custom-Field-Types)\
\ that the [Custom Fields](#tag/Custom-Fields) is based on.\n - ``text_value``: A primitive string\n\
\ - ``date_value``: An ISO8601 date-time\n - ``hash_value``: A JSON object for [Custom Fields](#tag/Custom-Fields)\
\ which store complex data structures\n\n### Pairing\n\nMultiselect custom fields can be paired with\
\ [label sets](/api/documentation/v2#tag/Label-Sets) (`paired_label_set`), with the field’s options\
\ paired to the label set’s labels (`paired_label`). Once this pairing is established, the application\
\ will automatically do bidirectional syncing: choosing the multiselect’s options will apply the corresponding\
\ labels to the moment, and vice versa.\n\nBoth systems are supported, and the syncing should behave\
\ seamlessly, but at some point we will sunset the label system in favor of custom fields. We encourage\
\ using custom fields for new development.\n"
- name: Board Collaborators
description: '## Board Collaborators Overview
Board Collaborators allow opal users to add other users as a collaborator on their **private** Boards.
This allows the Collaborators to view and edit the Board as if they were the owner.
Because **public** Boards are already available to any user in your Workspace, they do not require
Board Collaborators. The endpoints are not available for these public Boards and will return error
messages accordingly.
'
- name: Board Objects
description: "## Overview\n- **[Board](#tag/Boards/operation/CreateBoardV3)**: A board is the parent\
\ container and encapsulates its Board Objects and Board Object Collections\n- **[Board Object Collection](#tag/Boards/operation/CreateBoardObjectCollectionV3)**:\
\ A Board resource can have zero-or-many Board Object Collections. These allow for logically grouping\
\ Board Objects. \n- **[Board Object](#tag/Board-Objects/operation/CreateBoardObjectV3)**: Board Objects\
\ encapsulate an Opal resource in a way which allows that resource to exist on a Board or Board Object\
\ Collection. A board object can represent the following by specifying the corresponding ``relationship``\
\ when creating the Board Object:\n - [Moment](#tag/Moments/operation/CreateMomentV3)\n - [Rich\
\ Text Document](#tag/Rich-Text-Documents/operation/CreateRichTextDocumentV3)\n - Note that Rich\
\ Text Documents included with Board Objects will not have an `assets` relationship. Instead, you\
\ should use the `asset_references` relationship."
- name: Bulk Operations
description: "## Bulk Operations\n\nA Bulk Operation represents a number of individual actions to be\
\ performed.\n\n### Terms\n- **``Operation ID``**: A unique string identifier that corresponds to\
\ a\n specific individual operation that can be made for a resource. If the request\n is usable\
\ in the context of a bulk operation, the endpoint will have this\n identifier documented as \"Operation-ID\"\
.\n"
- name: Categories
description: "## Overview\n\nCategories are in a tree: a given category has zero or more ancestors and\
\ zero or more descendants. The tree is built by recursively following `parent_category` relationships.\
\ Currently our trees are at most two nodes deep (that is, a root with zero or more leaves), but clients\
\ **MUST** be able to handle trees of any depth.\n\n### Category type and custom fields\n\nCategories\
\ can be associated with [Category Types](/api/documentation/v3#tag/Category-Types), determining which\
\ [Custom Fields](/api/documentation/v3#tag/Custom-Fields) are available to [Blocks](/api/documentation/v3#tag/Blocks)\
\ in the category. If the category has a relationship with a deactivated category type it is considered\
\ to have no category type.\n\n### <q>Effective</q> category type\n\nThe <q>effective</q> category\
\ type allows the category to inherit a category type relationship.\n\n*Note:* The following description\
\ of the algorithm is informational: clients that want the <q>effective</q> category type **MUST**\
\ use the `effective_category_type_id` property in the category resource object’s `meta` information,\
\ and **MUST NOT** manually compute the value using this algorithm, as the exact behavior may change\
\ without warning.\n\nIf the given category has a relationship with an active (not deactivated, not\
\ deleted) category type that is the <q>effective</q> category type.\n\nIf the given category does\
\ *not* have a relationship with an active category type, any ancestors that have a relationship with\
\ an active category type are selected, and the nearest ancestor (the ancestor with the largest `depth`)\
\ provides the <q>effective</q> category type.\n\nIf the given category has no ancestors, or none\
\ of its ancestors have a relationship with an active category type, *and* the view *does* have a\
\ relationship to an active category type, the view’s category type is the <q>effective</q> category\
\ type.\n\nIf none of the above conditions are met, the category does not have an <q>effective</q>\
\ category type.\n\n*Note*: The behavior doesn’t change based on where the given category is in the\
\ tree — the logic is the same for the root, leaves, and everything in-between. This is why the following\
\ table refers to ‘parent’ and ‘grandparent’, rather than using tree terminology.\n\nIn the following\n\
* ‘✓’ means the column’s entry is associated to an active category type\n* the parent and grandparent\
\ demonstrate inheritance behavior if the given category has ancestors\n with an associated active\
\ category type\n\n | view | grandparent category | parent category | given category | <q>effective</q>\
\ category type comes from… |\n | :----: | :--------------------: | :---------------: | :--------------:\
\ | -------------------- |\n | | | | ✓ \
\ | given |\n | | | ✓ | ✓ \
\ | given |\n | | ✓ | |\
\ ✓ | given |\n | ✓ | | \
\ | ✓ | given |\n | | | ✓ \
\ | | parent |\n | | ✓ | ✓ \
\ | | parent |\n |✓ | \
\ | ✓ | | parent |\n | | ✓ \
\ | | | grandparent |\n | ✓ | ✓ \
\ | | | grandparent |\n | ✓ | \
\ | | | view |\n | | \
\ | | | \U0001F6AB (no category type) |\n"
- name: Onboarding
description: "## Onboarding Overview\nUnlike many other Opal endpoints, the Onboarding endpoints are\
\ only accessible via a special OAuth scope that is not currently offered to Opal customers (i.e.\
\ it is internal-use only).\n\nThe `trial_invites` `POST` endpoint is JSON:API compliant, but the\
\ `trial_invites/do/accept` endpoint is capable of serving up either a JSON RPC response or redirecting\
\ to a user onboarding web page depending on whether HTML or JSON is specified in the request's `Accept`\
\ header.\n\nThe process of requesting an invitation and accepting it is always two steps:\n1. A `POST`\
\ request to `onboarding/v3/trial_invites` creates a trial invite and produces an `accept` link that\
\ is included in the response body.\n2. A user follows the `accept` link in a browser and is redirected\
\ into the user setup process OR a client makes an RPC request to the `accept` link and receives a\
\ `user_setup` link a user can follow to begin profile setup in a JSON response body.\n\nThere is\
\ optionally a third step. If the `user_setup` link in the `accept` request's response is not used\
\ to get the user into their setup flow, a `GET` request to `onboarding/v3/trial_invites/status` can\
\ be sent in order to retrieve a `trial_invite` record that surfaces the `user_setup` link as well.\n\
\n### Setting up a new integration\nThe internal-only process of creating a new onboarding integration\
\ starts with creating a new onboarding client. From Opal's Hydra admin CLI, choose the \"create onboarding\
\ client\" option. Fill out the required information and take note of the Client Secret produced near\
\ the end of the process. This is the only time that client secret will be accessible. This secret\
\ should be saved in Opal's shared Engineering vault in 1Password.\n\nNext, a third party integration\
\ that creates new Opal trials can be set up with the newly created Hydra client in one of two ways.\
\ Either it can make a Client Credentials OAuth 2.0 token request using the client secret and then\
\ make authenticated requests with the token it receives in response, or you can set the third party\
\ integration up to use Opal's `trial_invites` endpoint as a webhook (see below).\n\n#### Webhook\
\ usage\nIf you want to create a token and treat it like an API key while using the `trial_invites`\
\ endpoint as a webhook, you should request an OAuth token by hand and use that token in the third\
\ party integration as a long-lived API key.\n\nFrom the Hydra admin CLI, select the onboarding client\
\ you created for the purposes of this integration. Next choose the \"Show sample auth URL and curl\
\ commands\" option. You will get a CURL command like the following:\n```shell\ncurl -X POST \\\n\
\ https://login.ouropal.com/oauth2/token \\\n -H 'Content-Type: application/x-www-form-urlencoded'\
\ \\\n -d \"client_secret=<SECRET>&client_id=onboarding1--742d8aff84759a6c&grant_type=client_credentials&scope=write:onboarding\"\
\n```\n\nReplace `<SECRET>` with this client's secret, replace `https://login.ouropal.com` with whichever\
\ Opal domain you are working against, and make the request from a shell on your laptop (just needs\
\ internet access and `cURL` installed). This will produce JSON similar to the following:\n```json\n\
{\n \"access_token\": \"dRGg4JW0F9QIHBnZpkLHWJ7j748AsALcL4_UfmjI0-4.VYbLrAiQzqgrmgXClQhmICP2_7BBEp9OMgKO9lpyUjU\"\
,\n \"expires_in\": <a long time>,\n \"scope\": \"write:onboarding\",\n \"token_type\": \"\
bearer\"\n}\n```\n\nNow take your `access_token` and plug it into an Authorization header for whatever\
\ webhook request to `onboarding/v3/trial_invites` your new integration is going to make:\n```\nContent-Type:\
\ application/json\nAccept: application/json\nAuthorization: Bearer dRGg4JW0F9QIHBnZpkLHWJ7j748AsALcL4_UfmjI0-4.VYbLrAiQzqgrmgXClQhmICP2_7BBEp9OMgKO9lpyUjU\n\
```\n"
- name: Rich Text Documents
description: '## Overview
### Client libraries and document formats
Rich Text Document endpoints can accept documents in arbitrary formats. The `client_library` attribute
identifies the framework or library that generated the document.
Currently, the following formats are recognized, though other formats are allowed. When creating or
updating documents in these formats, ensure that the `client_library` attribute is consistent with
the value provided here:
| Format | Client Library ID |
| --------------------------------------- | ------------------ |
| [Tiptap 2](https://tiptap.dev) JSON | `tiptap/2.0` |
### Document assets
Some documents returned by these endpoints may have an `assets` relationship; these documents will
not also have an `asset_references` relationship.'
- 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<!--\n See the v2/secondary_resources.md file for examples\
\ of how to use this.\n-->\n"
- name: Blocks
description: "## Blocks\n### Loupe Resource Hierarchy\n\nThe Loupe endpoints are home to the core objects\
\ of Opal. \n\n#### Terms\n- **``Block``**: A building _block_ that represents a place in Opal to\
\ curate,\n organize, and share data.\n\n- **``View``**: A resource that represents a collection\
\ of blocks. It can hold\n certain filters and metadata associated with those blocks.\n\n- **``Category``**:\
\ An organizational structure used by some ``View``s to\n enable grouping of data. Categories can\
\ be nested hierarchically within\n other Categories.\n\n**Please note** that these definitions have\
\ fundamentally changed, as of\nNovember 2025. Previously, a `View` could be a top-level resource\
\ and\na `Block` was owned by a `View`, but we are in the process of inverting\nthis pattern, such\
\ that every `View` will now be owned by a `Block`.\n\n#### Notes\nThese endpoints are experimental,\
\ under active development, and may undergo\nbreaking changes at any moment. You **may** use them\
\ as a preview of upcoming\nwork but you **must not** use these endpoints for production use.\n\n\
### Access\n\nLoupe resources can be accessed by owners of the resources (originally the\ncreator\
\ or the resource) or by those who have been granted membership to the\nresource. Initially, access\
\ will grant view, edit, and delete permissions, but\nmore granular control of permissions will be\
\ forthcoming.\n\n### Pairing\nWhen supported by the category type of a block, blocks will be paired\
\ with\nmoments. Pairing is a way to represent the same resource as a Block within\nCampaign Planner\
\ and a Moment within Boards and the Calendar.\n\nThere are two ways to create a block and its paired\
\ moment. If you are creating\na new block from the perspective of campaign planning, you can just\
\ create the\nblock without specifying a paired moment and let the backend automatically\ncreate a\
\ paired moment for you. If you are creating a new block in order to\nrepresent an existing moment,\
\ create the block with a paired moment specified up\nfront. Importantly, pairing is always established\
\ by POSTing (creating) a new\nblock: Moments do store a reference to their paired block, but you\
\ cannot write\nto that relationship by PATCHing the moment. You instead POST a new block and\nthe\
\ new block will be set as the existing moment's paired block for you.\n\nWhen creating a new paired\
\ block with an existing moment, if you omit an `asset`\nbut the moment being paired with has a primary\
\ asset, the moment's asset will\nautomatically be set on the new block.\n\n### Plans Directory\n\
The Plans Directory (visible in the UI of the web application) shows all Blocks\nthat have the `browsable`\
\ property set to `true`. In the future, additional\ndirectories will make it so that more criteria\
\ applies, but for now, that is the\ndeciding factor.\n"
- name: Block Connectors
description: '## Block Connectors
Block connectors link blocks to views. A view can contain many blocks via block
connectors. A block can also belong to many views via block connectors.
In the current platform, blocks are expected to only be connected to one parent
view unless that block is "in support of" additional blocks. In the case that it
is "in support of" additional blocks, it should be connected (via block
connector) to those additional blocks'' views in a very specific way: It should
belong to those views'' "in support of" category. That category can be identified
by its `true` `is_supportive` attribute. There will only be one such category
per view (and all views have one automatically).
'
- name: Stories
description: Story moment migration operations
- name: Presentation Themes
description: Workspace brand presentation themes
x-tagGroups:
- name: Stable
tags:
- Board Collaborators
- Board Objects
- Boards
- Content Schedules
- Moment Schedules
- Moments
- Onboarding
- name: ⚠️ Unstable
tags:
- Block Connectors
- Board Columns
- Board Duplication
- Board Standard Columns
- Channels
- Custom Field Options
- Custom Field Types
- Custom Fields
- Moment Assignees
- Moment Custom Fields
- Planning Status
- Rich Text Documents
- User Groups
- Users
- Workspaces
- name: ℹ️ Proposed
tags:
- Bulk Operations
- Gem Chats
- Gem Files
- Moment Duplication
- Presentation Themes
- Workflows
- Workflow Contexts
- Workflow Stages
- Workflow Assignments
- Workflow Responses
- name: ⚛️ Experimental
tags:
- Blocks
- Block Custom Field Values
- Block Duplication
- Board User Settings
- Categories
- Category Types
- Charts
- Content
- Custom Field Colors
- Filter Sets
- Key Dates
- View Columns
- View Standard Columns
- Views
- View Colors
- Stories
- name: Additional Resources
tags:
- secondary_resources
components:
schemas:
asset:
title: asset
type: object
required:
- id
- type
- attributes
- links
- 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 file in bytes.
created_at:
type: string
format: date-time
nullable: false
description: An ISO8601 date-time.
readOnly: true
updated_at:
type: string
format: date-time
nullable: false
description: An ISO8601 date-time.
readOnly: true
links:
type: object
nullable: false
additionalProperties: false
required:
- v2_request
properties:
v2_request:
type: string
format: uri
relationships:
required:
- opal
type: object
nullable: false
additionalProperties: false
properties:
opal:
type: object
required:
- data
additionalProperties: false
properties:
data:
type: object
# --- truncated at 32 KB (6915 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/opal/refs/heads/main/openapi/opal-v3-openapi.yml