generated: '2026-08-01'
method: searched
source: https://developer-guides.cloudkitchens.com/api-reference/
docs: https://developer-guides.cloudkitchens.com/api-reference/
spec_source: openapi/cloudkitchens-public-api-openapi.yml
note: The scope reference is published inside the Authentication section of the CloudKitchens API reference and
  mirrored into the OpenAPI oauth2 flows, which is what these entries were read from. Scopes must be enabled for
  an application by CloudKitchens' internal team before they can be requested; once enabled they are toggled on
  the Application Settings page in the Developer Portal. Each endpoint declares the single scope it requires.
schemes:
- name: OAuth2.0
  source: openapi/cloudkitchens-public-api-openapi.yml
  flows:
  - flow: clientCredentials
    tokenUrl: /v1/auth/token
  - flow: authorizationCode
    authorizationUrl: /v1/auth/oauth2/authorize
    tokenUrl: /v1/auth/token
  description: "The **Authorization API** is based on the [OAuth2.0 protocol](https://tools.ietf.org/html/rfc6749),\
    \ supporting the (Client Credentials)[https://datatracker.ietf.org/doc/html/rfc6749#section-4.4] and the (Authorization\
    \ Code)[https://datatracker.ietf.org/doc/html/rfc6749#section-4.1] flows. Resources expect a valid token sent\
    \ as a `Bearer` token in the HTTP `Authorization` header.\n### Scopes\nScopes must be configured by our internal\
    \ team to be enabled for an app. Once the scopes are configured they can be enabled on the Application Settings\
    \ Page in Developer Portal. Each endpoint requires a given scope that can be verified on each endpoint documentation.\
    \ When generating an OAuth2.0 token multiple scopes can be requested.\n\n### Authorization Code Flow\nTo perform\
    \ this flow, the authorization code flow must be enabled in the Application Settings Page in Developer Portal.\
    \ When enabling the flow it is mandatory to provide a redirect URI pointing to your application. Once the flow\
    \ is complete we will redirect the user to this URI passing the 'code' and 'state' parameters.\nThe Authorization\
    \ Code flow provides a temporary code that the client application can exchange for an access token. To start\
    \ the flow the application must request the user authorization. This is done by sending a request to https://{{public-api-url}}/v1/auth/oauth2/authorize.\n\
    Example\n```\ncurl --location 'https://{{public-api-url}}/v1/auth/oauth2/authorize?client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&response_type=code&scope=organization.read&state=8A9D16B4C3E25F6A'\n\
    ```\nThis call will return a 302 redirecting the user to our authorization page. If the user approves the application,\
    \ we will redirect to configured URI passing the authorization code in the query parameter 'code'. The 'state'\
    \ parameter is also sent to ensure the source of the data.\nWith the authorization code, the client application\
    \ can generate the token.\n### Client Credentials Flow\nThe client_credentials flow does not require any steps\
    \ before generating the token. Once your application is ready, and the client_id and client_secret are available,\
    \ the token can be generated by following the instructions in the next section.\n\n### Generate Token\nTo generate\
    \ the token, use the `Client ID` and `Client Secret` (provided during onboarding), and optionally the authorization\
    \ code obtained after performing the Authorization Code flow, to the [Token Auth endpoint](#operation/requestToken)\
    \ endpoint. The result of this invocation is a token that is valid for a pre-determined time or until it is\
    \ manually revoked.\n\nThe access token obtained will be sent as a `Bearer` value of the `Authorization` HTTP\
    \ header.\n\nClient credentials in the request-body and HTTP Basic Auth are supported.\n\n#### Request Example\
    \ for client_credentials\n```\ncurl --location --request POST 'https://{{public-api-url}}/v1/auth/token' \\\n\
    \  --header 'Content-Type: application/x-www-form-urlencoded' \\\n  --data-urlencode 'scope=ping' \\\n  --data-urlencode\
    \ 'grant_type=client_credentials' \\\n  --data-urlencode 'client_id=[APPLICATION_ID]' \\\n  --data-urlencode\
    \ 'client_secret=[CLIENT_SECRET]'\n\n```\n#### Request Example for authorization_code\n```\ncurl --location\
    \ --request POST 'https://{{public-api-url}}/v1/auth/token' \\\n  --header 'Content-Type: application/x-www-form-urlencoded'\
    \ \\\n  --data-urlencode 'scope=ping' \\\n  --data-urlencode 'grant_type=authorization_code' \\\n  --data-urlencode\
    \ 'client_id=[APPLICATION_ID]' \\\n  --data-urlencode 'client_secret=[CLIENT_SECRET]' \\\n  --data-urlencode\
    \ 'code=[code]' \\\n  --data-urlencode 'redirect_uri=[redirect_uri]'\n\n```\n#### Response Example\n```\n{\n\
    \  \"access_token\": \"oMahtBwBbnZeh4Q66mSuLFmk2V0_CLCKVt0aYcNJlcg.yditzjwCP7yp0PgR6AzQR3wQ1rTdCjkcPeAMuyfK-NU\"\
    ,\n  \"expires_in\": 2627999,\n  \"scope\": \"ping orders.create\",\n  \"token_type\": \"bearer\"\n}\n```\n\n\
    ### Token Usage\n\nThe token provided in field `access_token` is used to authenticate when consuming the API\
    \ endpoints. Send the token value in the `Authorization` header of every request. The token expiration time\
    \ is represented in the field `expired_in`, in seconds. Currently, all tokens are valid for 30 days and should\
    \ be stored and re-used while still valid.\n\nNote that occasionally, a 401 error may be returned for a valid\
    \ token due to an internal service issue. Such occurrences should be rare. To prevent exposing potential vulnerabilities\
    \ to attackers, the Public API does not disclose other types of errors in the authentication flow if for any\
    \ reason the token can't be validated (when it's a valid token then it's ok to return 5XX or other 4XX though\
    \ - such as 403). In such scenarios, although the internal auth flow avoids retries to prevent attacks, if the\
    \ token is known to be valid and not expired, a retry with a backoff interval by the client is advised. Another\
    \ option is to request a new token.\n\n#### Example\n\n```\ncurl --location --request GET 'https://{{public-api-url}}/v1/ping'\
    \ \\\n  --header 'Authorization: Bearer <access_token>' \\\n  --header 'X-Store-Id: <storeId>'\n\n```"
scopes:
- scope: callback.error.write
  description: Token has permission to send failed webhook event results.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: catalog
  description: Permission to interact with product inventory for existing stores.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: delivery.provider
  description: Permission to provide delivery services for existing orders.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: direct.orders
  description: Permission to interact with direct order services.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: finance
  description: Permission to provide financial data for orders/stores.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: manager.loyalty
  description: Permission to interact with loyalty services.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: manager.menus
  description: Permission to manage menus.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: manager.orders
  description: Permission to manage orders.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: manager.storefront
  description: Permission to manage storefront.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: marketintel.service_integration
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.async_job.read
  description: Permission to read the status of a menu upsert job.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.entity_suspension
  description: Permission to notify the result of a menu entity availability update, after being requested by a
    webhook event.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.get_current
  description: Permission to send the current state of a menu, after being requested by a webhook event.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.publish
  description: Permission to notify the result of a publish menus operation for a given store.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.read
  description: Permission to read the current menus for a given store.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.sync
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.upsert
  description: Permission to create/update menus for a given store.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: menus.upsert_hours
  description: Permission to notify the receiving of the upsert hours menu event, after being requested by a webhook
    event.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: orders.create
  description: Permission to create new order for a given store.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: orders.read
  description: Permission to read orders and connected data.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: orders.update
  description: Permission to create and update new orders for a given store.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: organization.read
  description: Permission to read data for organization/brands/stores on behalf of a user.
  flows:
  - authorizationCode
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: organization.service_integration
  description: Permission to manage the your integration with a given store on behalf of a user.
  flows:
  - authorizationCode
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: ping
  description: Permission to ping the system.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: reports.generate_report
  description: Permission to request reports for given store(s) and period of time.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: reviews.reply
  description: Permission to reply to reviews.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: store.read
  description: Permission to query store information.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: storefront.store_availability
  description: Permission to send the current state of store.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: storefront.store_hours_configuration
  description: Permission to send the current store hours configuration.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: storefront.store_pause_unpause
  description: Permission to notify the result of a pause/unpause operation, after being requested by a webhook
    event.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml
- scope: stores.manage
  description: Permission to onboard stores and update the identifier.
  flows:
  - clientCredentials
  sources:
  - openapi/cloudkitchens-public-api-openapi.yml